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ABSTRACT 


The  Human  Factors  Engineering  for  User  System  Interface  (HFE/USI)  Specialty 
Group  has  conducted  several  evaluations  of  rapid  prototyping  tools  to  support  the  desi^  and 
development  of  user  interfaces  for  command  and  control  systems.  To  standardize  the 
evaluation  methodology,  we  compiled  a  list  of  command  and  control  criteria  and  rated  tools 
against  them.  These  ratings  can  used  to  select  a  tool  that  will  closely  match  the  needs  of  a 

MTTRE/ESD  program.  TMs  paper  describes  the  evaluation  methodology  and  applies  it  to  the 
review  of  the  following  tools:  VAPS,  LUIS/SMS,  SL-GMS,  DataViews,  TAE  Plus,  and 
SET. 
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EXECUTIVE  SUMMARY 


INTRODUCTION 

There  is  a  growing  interest  in  the  use  of  rapid  prototyping  for  the  design  and 
development  stages  of  govemment/military  system  acquisition.  Rapid  prototyping  is  a 
process  of  iteratively  refining  a  system  based  upon  the  user's  feedback.  The  prototype  can 
emulate  limited  functionality  of  Ae  "real"  system,  or  it  can  be  developed  into  a  deliverable 
system  itself. 

Prototyping  is  particularly  useful  in  the  design  and  development  of  user-system 
interfaces  (USIs).  As  the  system's  most  visible  part,  the  user  interface  can  have  a  great  effect 
upon  the  user’s  acceptance  of  the  system.  Use  of  USI  rapid  prototyping  tools  is  the  easiest 
and  quickest  approach  to  user  interface  design  and  development,  lliese  tools  encourage 
experimentation  by  maintaining  flexibility  of  design  in  the  development  of  ^phic  and  text- 
based  user  interfaces.  A  prototype  of  the  user  interface  provides  the  user  with  a  set  of 
functional  requirements  that  can  be  seen  and,  if  not  optimal,  modified  without  risking 
lengthier  development 

The  Human  Factors  Engineering  for  User  System  Interface  (HFE/USI)  Specialty 
Group  has  conducted  evaluations  of  USI  rapid  prototyping  software  tools  to  support 
MITRE/ESD  projects.  There  are  many  commercial-off-the-shelf  (COTS)  rapid  prototyping 
tools  on  the  market  today,  and  it  can  faie  an  ovorwhelming  task  to  sift  through  all  the 
literature.  To  make  tool  selection  easier,  we  are  presenting  our  evaluation  results  for  the 
following  tools: 

•  VAPS  by  Virtual  Prototypes 

•  Lockhet^  User  Interface  System  and  Softcopy  Mapping  System  (LUIS/SMS) 

•  Graphical  Modeling  System  by  SL  Corporation  (SL-GMS) 

•  DataViews  by  V.I.  Corporation 

•  Transportable  Applications  Environment  (TAE)  Plus  by  NASA/Goddard  Space 
Flight  Center 

•  Software  Engineering  Toolkit  (SET)  by  CASET  Corporation 
EVALUATION  METHODOLOGY 

To  standardize  the  evaluation  of  USI  r^id  prototyping  tools,  and  to  provide  a  basis 
for  comparison,  we  have  developed  a  list  of  evaluation  criteria  based  upon  t^ical 
government  and  military  requirements.  We  have  acquired  the  tools  and  used  them  to 
implement  model  command  and  control  application  user  interfaces.  Many  of  the  tools  were 
acquired  permanently  and  have  been  used  in  our  suppon  of  MITRE/ESD  pro^ams.  We 
have  evaluated  each  tool  against  the  list  of  criteria  and  developed  the  ratings  into  a  set  of 
"tools-at-a-glance"  tables.  If  a  new  tool  version  was  released  after  our  evaluation,  we 
presented  the  new  release's  modifications  and  enhancements  in  the  review.  We  also 
generated  an  overview  Ascription  and  a  summary  of  evaluation  results  for  each  tool. 


EVALUATION  CRITERIA 


The  evaluation  criteria  against  which  the  USI  rapid  prototyping  tools  are  evaluated 
fall  into  five  distinct  categories. 

•  Capabilities  refer  to  both  graphic  and  general  utility  functions  such  as 
geographical  map  generation,  zooming  and  panning,  labeling,  text  handling, 
display  objects,  windowing,  and  code  generation. 

•  Usability  issues  include  such  topics  as  direct  manipulation,  menuing,  precise 
object  placement,  environment  flexibility,  and  response  time.  The  amount  of 
programming  required  to  develop  a  prototype,  the  learning  curve  involved  in 
using  the  tool,  and  the  quality  of  the  documentation  are  also  discussed. 

•  Quality  of  the  vendor  support  encompasses  different  types  of  assistance 
throughout  the  development  process,  including  installation,  training,  and 
telephone  assistance. 

•  Hardware  issues  involve  such  topics  as  display  devices,  input  devices,  computing 
platforms,  and  portability. 

•  Software  issues  deal  with  adherence  to  industry  standards  and  compatibility  with 
other  commercial  software  tools. 


VAPS 

Manufacturer:  Virtual  Prototypes,  Inc.,  Montreal,  Canada 

Versions:  1.04, 2.05 

Platforms:  Silicon  Graphics,  Sun  4,  and  DECstation 

Cost:  $15,000  to  $41,000,  depending  on  the  configuration 

The  VAPS  Prototyping  System  is  a  high-end  USI  rapid  prototyping  tool.  VAPS 
provides  a  flexible  prototyping  environment  in  which  the  user  interface  can  be  modified 
quickly  and  easily.  It  consists  of  four  software  subsystems  that  collectively  provide  all  the 
capabilities  need^  to  quickly  implement  a  user  int^ace:  graphics  editor,  integration  menu, 
lo^c  editor,  and  runtime  manager. 

Although  VAPS  was  originally  developed  to  support  avionics  triplications,  it  can  also 
support  a  range  of  user  interface  applications.  It  is  particularly  useful  for  the  prototyping  of 
hardware  devices  such  as  equipment  and  display  consoles.  It  has  been  used  successfully  to 
prototype  control  panels  and  transceivers  for  a  tactical  system,  command  center  displays, 
instrumentation  panels,  tactical  radio  panels,  and  aircraft  cockpits. 

Evaluation  Summary 

Because  its  emphasis  is  on  objects  such  as  lights,  buttons,  knobs,  and  dials,  VAPS  is 
well-suited  to  the  modeling  of  hardware  devices.  A  user  input  logging  capability  has  been 
added  to  the  record  tiie  user's  actions.  Another  major  strength  of  VAPS  is  its  ability  to  allow 


VI 


a  developer  to  quickly  and  easily  build  and  modify  a  user  interface.  It  is  a  powerful  USI 
rapid  prototyping  tool  that  can  significantly  reduce  the  development  time  of  a  prototype  in 
comparison  to  many  other  commercial  rapid  prototyping  tools.  However,  VAPS  code  should 
be  optimized  to  minimize  overiiead  and  maximize  response  time.  Because  of  its  overhead 
requirements,  it  is  only  feasible  to  run  VAPS  on  high  performance  workstations,  such  as  the 
Silicon  Graphics  workstation. 

LUIS/SMS 

Manufacturer:  Lockheed  Missiles  and  Space  Company,  Inc.,  Austin,  Texas 

Versions:  LUIS  6.33b,  D;  and  SMS  6.63 

Platforms:  DECstation,  HP/Apollo,  Silicon  Graphics,  and  Sun  4 

Cost:  $50,000  for  both  LUIS  and  SMS 

LUIS/SMS  consists  of  an  integrated  environment  of  two  systems.  The  tirst  is  the 
Lockheed  User  Interface  System  (LUIS),  which  provides  a  deeply  nested  menuing  system  to 
support  development  of  a  user  interface.  The  second  is  the  Softcopy  Mapping  System 
(SMS),  which  supports  development  of  geographical  mapping  systems.  Although  LUIS  and 
SMS  can  both  run  as  stand-alone  systems,  they  were  developed  to  run  together.  LUIS 
provides  the  interface  through  which  the  user  can  interact  with  the  mapping  system.  Also, 
without  the  advantages  of  SMS'  special  mapping  capabilities,  there  are  many  user  interface 
development  systems  that  are  easier  to  use  than  LUIS.  As  a  package,  however,  LUIS/SMS 
provides  a  unique  set  of  capabilities.  The  newest  version,  LIJIS  n,  is  currently  being 
distributed. 

LUIS/SMS  was  designed  by  Lockheed  to  support  military  applications  that  involve 
geographical  maps.  It  can  support  many  different  levels  of  map  detail,  and  it  provides 
mechanisms  for  ensuring  optimal  performance. 

Evaluation  Summary 

The  strengths  of  the  integrated  LUIS/SMS  package  are  numerous.  First,  LUIS 
enables  the  ^veloper  to  create  the  user  interface  without  programming.  Through  a  complex 
menuing  system,  the  developer  can  create  both  the  "look"  and  the  "feel"  of  the  user  interf^ace 
independent  of  any  coding.  The  menus  allow  the  developer  to  specify  an  action  to  be 
executed  when  a  button  is  selected  or  deselected.  LUIS,  in  fact,  requires  coding  later  in  the 
development  process  than  do  many  other  rapid  prototyping  tools.  Coding  is  necessary  to 
bind  in  application  programs,  including  SMS  maps,  to  the  LUIS  interface. 

Another  major  strength  of  LUIS/SMS  is  that  it  combines  the  capabilities  of  user 
interface  design  with  map  display  generation.  This  unique  combination  is  very  useful  for 
command,  control,  communications  and  intelligence  (C3I)  applications.  LUIS/SMS  also 
provides  an  input  logging  feature  that  is  useful  for  performing  usability  testing  on  the  user 
interfaces  developed  with  LUIS/SMS.  Finally,  LUIS/SMS  runs  on  a  range  of  hardware 
platforms. 

Tradeoffs  are,  of  course,  involved  in  many  of  these  capabilities.  For  example,  the 
same  complexity  of  the  menuing  system  that  allows  the  developer  to  create  the  "look  and 
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feel"  of  the  interface  independent  of  programming  also  can  cause  the  tool's  interface  to  seem 
complicated  and  cumbersome.  Also,  although  programming  is  not  required  quite  as  early  in 
the  development  process  as  with  many  other  tools,  the  integrated  LUIS/SMS  does,  in  fact, 
require  a  substantial  amount  of  coding  to  create  a  mapping  application.  It  includes  over  300 
hi^-level  geographical  mapping,  display  object  manipulation  and  inter-process 
communication  (tetween  LUIS  and  external  applications,  including  SMS  a^  plications) 
programming  routmes.  There  is  a  steep  learning  curve  associated  with  the  tool. 

SL-GMS 

Manufacturer:  SL  Corporation,  Corte  Madera,  California 

Versions:  3.0f  1,4.0 

Platforms:  Sun,  Megatek,  Silicon  Graphics,  VAXstation,  HP  9000/3000/Apollo 

Cost:  $ 1 2,000  for  a  development  license; 

$2,500  for  a  runtime  license 

The  Graphical  Modeling  System  (SL-GMS)  is  a  rapid  USI  prototyping  tool  that 
supports  easy  generation  of  graphic  objects  and  assignment  of  dynamics  to  them.  SL-GMS 
consists  of  two  main  components.  First,  it  provides  an  easy-to-use  interactive  graphics  editor 
called  "SL-Draw,"  which  supports  development  of  dynamic  graphic  displays  and  objects. 
Second,  SL-GMS  provides  a  function  library  called  "SL-GMF'  whose  more  than  500 
routines  can  be  embedded  within  a  C,  Fortran,  Ada,  or  Pascal  control  program.  "Control 
program"  is  the  term  we  will  use  to  refer  to  the  program  that  "controls"  the  functionality  of  a 
prototype,  such  as  the  sequencing  of  displays,  the  appearance  of  a  pop-up  window,  or  the 
reading  of  text  input  from  the  end  user. 

SL-GMS  was  originally  developed  to  prototype  process  control  within  a 
manufacturing  environment,  but  it  has  evolved  into  a  general  purpose  tool. 

Evaluation  Summary 

SL-GMS  is  relatively  inexpensive  compared  to  some  of  the  higher-end  tools,  and  yet 
it  is  a  good  general  purpose  tool.  It  allows  the  "look"  of  the  prototype  to  be  free  from  all 
graphics  co^ng.  Screen  development  is  easy  and  flexible.  However,  because  display 
sequencing  cannot  be  defined  in  SL-Draw,  SL-GMS  does  require  programming  early  in  the 
development  process.  While  the  learning  curve  associated  with  SL-GMS  can  be  significant, 
it  is  not  as  steep  as  those  of  some  more  powerful  tools.  SL-GMS  also  minimizes  overhead, 
freeing  the  developer  from  worry  over  performance.  SL-GMS  is  a  tool  well-suited  to 
interfaces  that  require  simple  display  objects,  such  as  buttons  and  text  input  flelds,  and  do  not 
require  complex  geographical  maps. 
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TAE  PLUS 

NASA/Goddard  Space  Fli^t  Center ;  distributed  by  COSMIC, 

NASA's  software  distribution  center  located  at  the  University  of  Georgia 
4.1,5.! 

Sun  3/4,  Dec,  HP/ApoUo  workstations 
$500  for  the  general  public,  $250  for  the  government  for  4. 1 ; 

$750  and  $350  lespe^vely  for  5. 1 

TAE  Plus  is  a  ptmble,  X  Window-based  software  package  that  supports  design  and 
development  of  interactive  graphic  user  interface  application  systems.  Plus  consists  of 
two  main  subsystems:  the  Wr^bench  and  the  Window  Programming  Tools  (WPT).  The 
Workbench  is  the  primary  tool  for  user  interface  development  It  can  be  used  to  interactively 
create  or  edit  the  ^phic  portion  of  the  interface  and  generate  an  application  program.  The 
WPT  library  of  pro^amming  routines  handles  the  functionality  of  the  interface.  TAE  also 
provides  a  grapMcs  editor  ctdled  "Idraw,"  but  it  is  only  used  for  creating  and  customizing 
special  object  types;  all  the  interface  development  is  done  in  the  Workbench.  Version  5. 1 
was  relea^  in  May  1991.  TAE  Plus  is  based  on  the  X  Window  System,  XI 1  Release  3. 

Evaluation  Summary 

TAE  Plus  is  a  cost-effective  user  interface  development  tool.  It  is  particularly  useful 
for  developing  user  interfaces  that  require  a  wide  variety  of  interactive  display  objects  and 
have  a  fairly  well-defined  interface  design.  Its  development  environment  is  limit^  in 
flexibility,  but  it  provides  an  easy  interface  to  the  X  Window  System.  (Other  X-based  user 
interface  development  tools  include  Builder  Xcessory,  XBUILO  and  UIMX.) 

TAE  allows  the  developer  to  build  a  user  interface  under  X  Windows  without 
requiring  an  understanding  of  the  complexities  of  X.  However,  TAE  allows  the  developer  to 
access  the  X  toolkit  and  X  library  directly  if  necessary. 

TAE  Plus  supplies  a  wide  range  of  ready-made,  high-level  display  objects  such  as 
pull-down  menus,  check  boxes,  radio  buttons,  and  scroll  bars.  The  objects  in  4.1  are  based 
on  MTTs  Athena  widgets;  and  the  objects  in  5.1  are  based  on  MOTIF.  Therefore,  it  is  very 
useful  for  user  interfaces  that  require  many  different  interaction  styles. 

Periiaps  TAE  Plus'  most  important  strength  is  its  price.  It  offers  a  rather  complete  set 
of  high-level  display  objects  at  a  fraction  of  the  cost  of  the  other  tools  discussed  in  this  paper. 

Data  Views 

Manufacturer: 

Veraons: 

Platforms: 

Cost: 


V.I.  Corporation,  Northhampton,  Massachusetts 
7.0, 8.0, 9.0 

Sun,  HP/Apollo,  Data  General,  IBM  RS/6000,  VAXstation, 

DECstation,  and  Silicon  Graphics 

$17,000 


Manufacturer: 

Versions: 

Platforms: 

Cost: 


IX 


DataViews  is  a  product  of  V.L  Corporatitm.  It  is  a  general  purpose  USI  rapid 
prototyping  tool  that  allows  the  developer  to  build  a  dynamic  graphic  user  interface. 
DataViews  consists  of  two  major  components;  the  graphics  editor  DV-Draw,  and  the 
programming  library  DV-Tools.  DV-Draw  is  a  menu-^ven,  direct  manipulation  graphics 
editor  that  allows  displays  to  be  created,  animated,  and  executed  indepencknt  of  co^ng.  DV- 
Tools  is  an  extensive  library  of  routines  callable  from  user-supplied  "C"  code  that  suppon  the 
dynamics  and  functionality  of  the  interface. 

Like  SL-GMS,  DataViews  was  originally  developed  to  support  process  control 
manufacturing  applications,  but  has  become  a  more  general  purpose  tool. 

Evaluation  Summary 

DataViews  is  relatively  affordable.  It  is  particularly  useful  for  prototypes  that  require 
a  great  deal  of  dynamic  graphics.  DataViews  provides  a  good  graphics  editor  that  allows 
both  the  "look  and  feel"  of  the  prototype  to  be  defined  without  programming.  It  also 
provides  a  preview  function  that  allows  the  developer  to  test  the  functionality  of  the 
prototype  within  the  graphics  editor.  Its  dynamic  objects  can  be  driven  by  any  type  of  data 
source,  and  they  can  be  deflned  to  move  across  the  screen  with  real-time  positioning. 
However,  the  number  of  items  that  can  move  on  the  screen  at  one  time  is  limited. 

SET 

Manufacturer:  CASET  Corporation,  San  Juan  Capistrano,  California 

Versions:  3.4, 3.8 

Platforms:  Sun,  HP/ApoUo,  DEC  VAX,  DECstation  and  VAXstation,  Silicon 

Graphics  and  the  PRIME  SO  Series 
Cost:  $7,500  for  all  five  modules; 

$2,000  for  each  individual  module 

SET  is  useful  for  developing  prototypes  that  are  primarily  text-based  and  require  a 
minimal  selection  of  display  objects.  It  provides  a  suite  of  programming  libraries,  and  it  is  a 
programming-intensive  tool.  SET  has  undergone  a  fairly  extensive  upgrade  since  it  was  fu-st 
released,  and  version  3.8  has  become  a  markedly  better  user  interface  design  tool  than  the 
original  release  of  SET.  Although  it  does  not  directly  support  geographical  mapping,  a  new 
module  that  provides  raster  and  vector  graphics  capabilities  became  available  September 
1991.  Also,  version  3.8  is  compatible  with  the  X  Window  system  and  Motif. 

Evaluation  Summary 

SET  version  3.4  is  a  useful  tool  for  expert  developers  who  would  rather  develop  a 
prototype  through  high-level  programming  with  the  routine  libraries  than  through  use  of  a 
menuing  system  or  (tirect  manipulation.  Unlike  many  of  the  other  tools,  SET  has  undergone 
an  extensive  set  of  modifications  during  the  last  two  releases.  An  interactive  graphics  editor 
was  added;  the  documentation  was  improved;  and  the  tool  was  made  X/Motif  compatible. 
Use  of  the  libraries  can  be  a  signiticant  improvement  over  coding  from  low-level  graphics 
packages,  such  as  CORE  or  GKS.  However,  the  SET  programming  libraries  can  present  a 
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significant  learning  curve  even  for  expert  programmers,  simply  because  of  the  poor 
dtxumentadon. 

CONCLUSIONS  AND  RECOMMENDATIONS 

There  is  no  one  "best"  USI  rapid  prototyping  tool.  Selection  of  a  tool  must  be  based 
upon  the  particular  needs  of  a  given  system.  E^u:h  of  the  tools  has  its  own  strengths  and 
weaknesses,  and  these  should  dtted  to  the  system  requirements.  For  example,  if  a 
prototype  requires  high-level  display  objects  such  as  scrolling  text  windows  and  pull-down 
menus  superimposed  on  complex  geographical  map  data,  LUIS/SMS  would  be  preferable. 

If,  on  the  other  hand,  the  prototype  is  to  be  a  simulation  of  an  Air  Force  display  console, 
complete  with  dials  and  buttons,  VAPS  would  be  the  ^propriate  tool.  DataViews  and  SL- 
GMS  might  be  considered  fw  the  development  of  a  more  general  purpose  prototype,  such  as 
different  applications  of  computer  information  systems.  TA£  Plus  might  chosen  for  a 
prototype  that  requires  many  high-level  display  objects  such  as  radio  buttons,  check  boxes, 
and  scroll  bars,  but  has  a  limited  budget  ^yond  functional  requirements,  it  is  important  to 
consider  skills  and  training.  For  example,  developers  who  have  a  great  deal  of  experience 
with  software  development  may  choose  to  use  SET,  which  is  very  programming-oriented. 

The  ’Tools-At-A-Glance"  tables  (appendix)  can  be  used  to  determine  the  tool  best 
suited  to  an  application.  To  do  so,  the  user  can  select  a  subset  of  pertinent  criteria  and  pick 
the  tool  that  was  rated  highest  against  them.  It  may  also  be  beneficial  to  use  the  ratings  in  a 
weighted  factor  analysis  to  determine  which  tool  to  select.  To  use  this  approach  can  assign 
numerical  weights  to  the  criteria,  according  to  importance.  Numerical  values  can  also  be 
assigned  to  the  rating:  three,  two  and  one  ftn*  check  plus,  check,  and  check  minus, 
respectively.  Next,  multiply  the  numerical  rating  scores  by  each  weight  factt>r,  and  add  the 
total  for  each  tool  The  tool  with  the  highest  total  score  is  the  "best"  match  for  the 
application. 

Similarly,  the  evaluation  criteria  can  be  used  as  a  basis  for  other  evaluations.  To 
conduct  an  evaluation  of  a  tool  not  included  in  this  paper,  compile  a  list  of  pertinent  criteria. 
Next,  desi^  a  model  benchmark  prototype  that  incorptmtes  aU  these  criteria.  Finally,  use 
the  tool  to  implement  the  benchmark  application.  In  this  way,  the  degree  to  which  the  tool 
supports  each  of  the  criteria  can  be  rat^ 

In  conclusion,  USI  rapid  prototyping  tools  can  be  critical  to  the  development  of  high- 
quality  user  interfaces.  Prototyping  lifts  a  (ksign  from  paper  and  allows  the  user  to 
physically  "see  and  feel"  the  system  specifications.  Prototyping  tools  ^vide  the  system 
developer  with  the  power  and  flexibility  to  experiment  with  design  options.  Because  these 
tools  are  often  expensive,  MITRE/ESD  projects  may  want  to  delay  purchasing  one  until  they 
are  confident  it  suits  their  needs. 

The  HFEAJSI  Specialty  Group  can  assist  in  this  effort.  We  have  many  of  the  current 
USI  prototyping  tools  in-house.  We  are  prepared  to  present  demonstrations  of  our  in-house 
tools.  We  also  evaluate  new  tools  upon  request.  As  new  USI  rapid  prototyping  tools 
emerge  on  the  market,  we  will  continue  to  evaluate  them  and  update  future  editions  of  this 
paper  with  the  results. 
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SECTION  ONE 


BACKGROUND 


1.1  PURPOSE 

Over  the  past  decade,  there  has  been  a  growing  interest  in  the  use  of  rapid  prototyping 
fOT  the  design  and  develq)ment  stages  of  system  acquisition.  Because  r^id  prototyping 
involves  iterative  refinement  of  a  system  based  on  feedback  from  the  user,  it  can  align  a  system 
closely  to  user  specifications,  and  improve  user  acceptance  of  the  final  system. 

Prototyping  is  particularly  useful  in  the  design  and  development  of  user  interfaces.  The 
interface  between  the  user  and  the  system  is  the  system's  most  visible  pan,  and  so  has  a  great 
effect  upon  user  acceptance.  A  prototype  of  the  user  interface  provides  the  user  with  a  set  of 
functional  requirements  that  can  be  seen  and  refined. 

Use  of  rapid  prototyping  tools  is  the  easiest  and  quickest  approach  to  designing  and 
develo^g  user  interfaces.  These  tools  encourage  experimentation  by  maintaining  flexibility  of 
desi^  in  the  development  of  graphic  and  text-based  user  interfaces.  MITRE's  Human  Factors 
Engineering  for  User  System  Int^ace  (HFEAJSI)  Specialty  Group  has  been  involved  in  the 
evduation  of  USI  rapid  prototyping  software  tools  to  support  MITRE/ESD  projects.  There  are 
many  conmeicial-off-tlK-shelf  (COTS)  rapid  p^otyping  tools  on  the  market  today,  and  it  can 
be  an  overwhelming  task  to  sift  through  all  the  literature.  To  make  tool  evaluation  easier,  we 
report  here  our  evaluations  of  six  USI  rapid  prorotyping  tools: 

•  VAPS  by  Virtual  Prototypes 

•  Lockheed  User  Interface  System  and  Softcq)y  Mapping  System  (LUIS/SMS) 

•  Graphical  Modeling  System  by  SL  Corporation  (SL-GMS) 

•  DataViews  by  V.I.  Corporation 

•  Transportable  Applications  Environment  (TAE)  Plus  by  NASAAToddard  Space 
Flight  Center 

•  Software  Engineering  Toolkit  (SET)  by  CASET  Corporation 

The  results  can  be  used  by  MTTRE/ESD  projects  in  selecting  tools  to  fit  their  needs. 

1.2  METHODOLOGY 

To  standardize  evaluation  of  the  user  interface  rapid  proto^ing  tools  and  to  provide  a 
basis  for  comparing  them,  we  developed  a  list  of  evaluation  criteria.  We  surveyed  various 
government  and  military  applications  tt)  determine  common  functionality  requirements  and 
implementation  preferences.  We  defined  and  then  categorized  the  criteria;  the  categories  include 
capability,  usability,  vendor  support,  and  software  and  hardware  issues. 
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To  expedite  the  process  of  recording  our  evaluation  results,  we  developed  a  set  of 
questions  that  address  the  major  points  of  each  evaluation  critraion.  We  acquired  each  of  the 
tools  for  a  trial  evaluation  period,  and  used  them  to  build  model  command  and  control 
application  user  interfaces  for  a  period  of  at  least  three  months.  (For  more  details  on 
benchmark  applications,  see  "Evaluating  Gr^hical  User  Interface  Tools  for  Command  and 
Control  Applications,"  Daniel  J.  Kurys,  National  Computer  Graphics  Association  Annual 
Conference,  March  1990).  Many  of  the  tools  were  acquired  permanently  and  have  been  used 
to  support  our  softshell  work  for  MITRE/ESD  programs. 

As  we  used  each  tool,  we  evaluated  it  against  the  list  of  criteria.  The  tools  were  rated 
on  a  three-point  scale: 

•  Directly  supports  this  criterion  (check  plus) 

•  Can  support  the  feature  but  requires  additional  effort  by  the  developer  (check) 

•  Does  not  support  this  criterion  at  all  (check  minus) 

For  criteria  such  as  compatibility  with  input  devices  and  hardware  platforms,  the  ratings  mean 
the  following:  "check  plus"  means  the  tool  can  support  more  than  two;  "check"  means  the  tool 
supports  two;  and  "check  minus"  means  it  supports  only  one.  These  ratings  were  placed  in  a 
set  of  "tools-at-a-glance"  tables.  Finally,  we  generated  an  overview  description  and  a  summary 
of  evaluation  results  for  each  tool. 

To  select  a  USI  rapid  prototyping  tool,  use  the  following  three-step  process: 

•  Identify  pertinent  criteria  and  assign  them  numerical  weights  according  to  relative 
importance 

•  Evaluate  the  tools  against  the  criteria 

•  Develop  a  decision  matrix  as  shown  in  section  4 

1.3  SCOPE 

Section  2  defines  and  lists  questions  for  each  of  the  evaluation  criteria.  The  questions 
can  support  the  reader  in  evaluating  a  tool  not  included  in  this  paper.  The  tool  overviews  and 
evaluation  results  are  summarized  in  section  3.  Section  4  rep<^  our  conclusions  and 
recommendations  based  upon  the  evaluation  results.  A  decision-making  chart  that  can  be  used 
for  selecting  a  tool  is  also  shown.  The  "tools-at-a-glance"  tables  are  contained  in  the  appendix. 
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SECTION  TWO 


EVALUATION  CRITERIA 


2.1  INTRODUCTION 

The  criteria  against  which  the  tools  are  evaluated  fall  into  five  distinct  categories: 
capability,  usability,  vendor  support,  hardware  issues,  and  software  issues. 

Capabilities  include  both  graphic  and  general  utility  functirais  that  can  assist  in  the 
prototyping  process.  Examples  are  geographical  map  generation,  zooming  and  panning, 
labeling,  text  handling,  display  objects,  windowing,  and  code  generatitMi. 

Usability  issues  include  such  topics  as  direct  manipulation,  menuing,  precise  object 
placement,  environment  flexibility,  and  respcmse  time  for  the  tool  itself.  The  amount  of 
programming  required  to  develop  a  protot)^,  the  learning  curve  involved  in  using  the  tool, 
and  the  quality  of  the  documentaticm  are  also  discussed. 

Quality  of  the  vendor  support  is  a  third  key  issue  in  the  evaluation  of  a  rapid 
prototyping  tool.  It  can  encompass  different  types  of  assistance  throughout  the  life  cycle  of  the 
development  process,  including  installation,  training,  and  telephraie  assistance. 

Hardware  issues  include  topics  such  as  display  devices,  input  devices,  computing 
platforms,  and  portability. 

Software  issues  deal  with  concerns  such  as  adherence  to  industry  standards  and 
compatibility  with  other  commercial  software  tools. 

Before  proceeding  to  individual  tool  evaluatitms,  we  will  examine  each  of  these 
categories  in  detail,  and  pose  the  questions  that  should  be  asked  as  part  of  the  evaluation 
process. 

2.2  CAPABILITY  ISSUES 
2.2.1  Geographical  Mapping 

Since  mapping  capabilities  are  an  important  part  of  many  C2  displays,  it  is  often 
important  to  be  able  to  turn  geographical  maps  into  prototypes.  Rapid  prototyping  tools  can 
support  mapping  capabilities  at  two  different  levels.  They  can  directly  supprat  develq)ment  of 
vector-drawn  maps  or  import  maps  from  outside  sources.  A  few  rapid  prototyping  tools 
directly  support  (tevelqrment  of  geographical  mapping  systems.  These  tools  accept  input  data 
and  create  complex  geographical  maps  from  it  Many  tools  provide  for  importing  mtq>s  from 
external  sources. 
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Evaluation  Questions: 

•  Does  the  tool  support  a  wide  variety  of  available  vector  and  raster  map  formats 
(World  Database  I,  n,  DTED,  DFAD,  SPOT,  etc.)? 

•  If  so,  was  it  a  difficult  process? 

2.2.2  Graphics  Manipulation 

The  manipulation  of  graphics  includes  fimctions  such  as  zooming,  panning,  and 
resetting.  Rapid  prototyping  tools  can  support  a  variety  of  zooming  factors.  The  zooming 
factors  control  to  what  degree  the  ^phics  enlarge  or  shrink  each  time  the  "zoom  in"  or  "zoom 
out"  function  is  invoked.  Panning  is  also  assigned  a  factor.  Panning  refers  to  the  ability  to 
move  a  graphic  display  from  the  current  position  to  the  right,  left,  up,  or  down.  The  amount  of 
movement  relative  to  Ae  graphics  is  controlled  by  the  panning  factor.  The  reset  function 
undoes  any  zooming  or  panning  that  has  been  done,  returning  the  graphics  to  the  previous 
position.  These  types  of  manipulations  ate  useful  for  maps  as  well  as  other  types  of  graphics. 

Evaluation  Questions: 

•  Does  the  tool  support  zooming,  panning  and  resetting  graphics? 

•  Did  you  find  these  functions  easy  to  implement? 

2.2.3  Toggle  Overlays 

Toggle  overlays  allow  each  level  of  graphics  to  be  superimposed  (hi  the  previous  level. 
For  example,  in  a  moping  application,  the  picture  may  begin  with  a  simple  depiction  of  the 
country  borders.  Major  roads,  rivers,  cities,  terrain  shading,  and  elevation  shading  can  then 
each  be  added  to  form  a  compc»ite  picture.  Toggte  overlays  permit  each  separate  part  of  the 
picture  to  be  toggled  on  or  off  independently,  improving  die  tool's  performance.  Thus  toggling 
off  the  city  names  would  not  require  that  the  total  picture  be  redrawn. 

Evaluation  Questions: 

•  Did  the  tool  provide  for  management  of  graphic  overlays? 

•  Did  the  toggle  overlays  meet  your  needs  for  manipulating  different  types  of  data? 

2.2.4  Labels 

Labels  include  pictures  as  well  as  alphanumerics.  Both  types  of  labels  may  be  used  as 
part  of  selectable  display  objects  such  as  buttons  and  pull-down  menus.  Alphanumeric  labels 
are  ffequendy  used  in  command  and  control  user  interfaces.  Examples  of  picture  labels  are  the 
folder,  file,  and  trash  can  ictms  commonly  us^  in  word  processing  tools.  They  are  also  called 
icons. 


A  useful  feature  causes  labels  to  revo^  video  as  the  cursor  moves  over  them;  for 
example,  each  option  button  within  a  pull-down  menu  reverses  video  as  the  cursor  passes  over 
it,  and  then  returns  to  its  original  appearance  when  the  cursor  is  gone.  Alphanumeric  labels  can 
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also  be  used  as  static  (non-selectable)  labels.  For  example,  a  static  label  may  be  used  to  display 
such  information  as  "ALERT"  or  "DEFCON  3".  It  is  often  useful  to  be  able  to  define  these 
static  labels  to  flash  on  the  screen.  Typical  adjustable  attributes  for  alphanumeric  labels  include 
font  size  and  style. 

Evaluation  Questions: 

•  Does  the  tool  support  alphanumeric  and  picture  labels? 

•  Was  it  difficult  to  cause  the  labels  to  reverse  video  as  the  cursor  passed  over  them? 

•  Was  it  difficult  to  cause  static  text  warnings  to  flash? 

•  Does  the  tool  support  development  of  specialized  symbology? 

2.2.5  Text  Handling 

Text  editing  C2q)abilities  deal  with  the  usability  of  a  particular  high-level  display  object  called  a 
"text  field."  Text  fields  are  areas  on  the  screen  within  which  the  user  can  input,  and  the  system  can 
ouq)ut,  single  or  multiple  lines  of  text  The  fields  can  be  ftxmatted  or  unformatted.  An  example  of  a 
formatted  field  is  in  which  the  user  is  prompted  by  the  formatting  to  input  a  date. 

It  is  useful  for  a  (nototyping  tool  to  allow  default  values  to  be  defined  for  text  fields. 

Default  values  can  simplify  the  user's  workload.  They  can  also  be  used  as  an  example  of  the 
type  of  data  that  should  be  entered  into  a  particular  field. 

Navigation  between  text  fields  may  be  done  by  a  pointing  device  or  keyboard.  To 
select  a  text  field,  the  mouse  cursor  may  simply  be  placed  within  the  field,  or  the  mouse  button 
may  need  to  be  clicked  while  the  cursor  is  wit^  it  Typically,  a  special  "insertion"  cursor 
indicates  the  point  at  which  the  text  will  be  inserted. 

Evaluation  Questions: 

•  Does  the  tool  supply  text  handling  capabilities? 

•  If  so,  can  the  text  fields  be  used  for  input  and  output? 

•  Can  they  be  formatted? 

•  Was  it  easy  to  navigate  fiom  text  field  to  text  field? 

2.2.6  High-level  Display  Objects 

There  is  a  range  of  high-level  display  objects  that  a  rapid  prototyping  tool  may  or  may 
not  support  A  "high-level"  object  refers  to  a  composite  object  such  as  a  selectable  button,  as 
qjposed  to  primitive  objects  such  as  the  rectangle  and  text  which  may  comprise  it  Direct 
support  of  a  display  object  means  that  the  tool  provides  the  object  re^y-made  to  the  prototype 
developer  rather  than  providing  the  primitive  objects  with  which  to  build  it  Typical  liigh-level 
display  objects  are  selectable  buttons,  radio  buttons,  check  boxes,  labels,  text  pull-down 
menus,  pop-up  windows  and  scroll  bars. 
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High-level  display  objects  can  greatly  simplify  the  prototype  development  process. 
They  are  most  often  provided  to  the  protot)^  developer  as  either  selectable  buttons  within  a 
graphics  editor,  or  programming  calls  within  a  programing  routine  library. 

Evaluation  Questions: 

•  What  high-level  display  objects  does  the  tool  directly  support? 

•  What  primitive  objects  does  it  support? 

•  Through  what  mechanism  does  the  tool  provide  you  with  these  objects? 

•  Can  you  modify  these  "ready-made"  objects? 

•  If  so,  to  what  degree? 

•  Does  it  provide  the  high-level  objects  needed  in  your  application? 

2.2.7  Windowing 

Windowing  capabilities  can  be  useful  during  development  and  runtime.  They  can  allow 
the  prototype  devel(^)ff  to  make  modifications  to  the  protot^  in  one  wiiKlow  while  watching 
it  run  in  another  window.  They  can  also  help  a  prototype  to  use  screen  "real  estate"  efficiently. 
Windowing  should  be  accompanied  by  convenient  windowing  ctmtrols,  such  as  resize, 
relocate,  minimize  or  maximize,  raise  or  lower,  and  scrolling  capabilities.  These  types  of 
controls  are  usually  accessible  through  a  menuing  system.  Resize  allows  the  size  of  the 
window  to  be  adjusted.  Relocate  allows  the  window  to  be  placed  anywhere  on  the  screen. 
Nfinimize  and  maximize  allow  the  window  to  be  adjusted  auunnatically  to  its  smallest  or  largest 
size.  The  "raise"  capability  selects  one  window  to  be  the  active  window;  usually  the  user 
clicks  on  that  window  with  the  mouse  and  the  selected  window  is  automatically  placed  in  front 
of  any  other  open  windows.  This  is  called  "raising"  the  window.  "Lowering"  a  window  is 
placing  a  window  behind  other  open  windows.  Scrolling  may  be  available  along  the  vertical  or 
horizontal  edge  of  the  window,  or  along  both. 

Evaluation  Questions: 

•  Did  the  tool  provide  scnne  type  of  windowing  capability? 

•  If  so,  did  the  tool  also  provide  convenient  window  control  features? 

•  Upon  what  windowing  systems  were  these  feamres  based:  X,  SunViews, 
DECWindows? 

2.2.8  Code  Generation 

An  iy)plication  program  may  be  developed  automatically  by  a  software  tool.  When  it  is, 
the  generated  code  is  based  upon  irdformation  specified  in  a  form  rather  than  by  programming. 
The  application  program  can  be  generated  in  various  languages,  such  as  C  or  Fortran  which  are 
compiled,  or  a  user  interface  language  (UIL)  which  is  interpreted  at  runtime.  In  the  case  of 
rt^id  prototyping,  the  code  that  is  need^  is  an  application  program  that  will  handle  the 
sequencing  of  tlw  displays.  The  generated  code  includes  the  subroutines  and  functions  that 
support  the  interaction  of  the  prototype.  The  degree  to  which  the  application  program  requires 
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modification  by  the  user  can  vary  between  tools.  For  example,  the  code  generation  process  may 
generate  only  subroutine  headings  and  peiii^s  a  main  routine;  the  user  must  then  add  the 
executable  commands.  Or  the  generate  code  may  include  the  subroutines  and  some  of  the 
details  of  the  prototype  functionality.  In  that  case  the  user  need  make  only  minor  modifications. 

Evaluation  Questions: 

•  Did  the  tool  contain  a  code  generation  feature? 

•  What  type  of  code  did  it  generate? 

•  If  so,  how  complete  was  the  code? 

•  How  extensive  were  the  modifications  you  needed  to  make  to  the  code? 

•  Can  the  code  be  modified  and  executed  in  the  develq)ment  environment? 

2.2.9  User  Input  Logging 

Some  rapid  prototyping  tools  provide  user  input  logging  as  a  means  of  recording  the 
user’s  commands  and  input  device  actions.  The  user  log  is  usually  written  into  a  computer  file 
and  lists  and  time-stamps  each  entry.  User  inputs  can  include  any  action  accomplished  through 
any  input  device,  such  as  a  keyboard,  mouse,  track  ball  or  light  pen.  The  inputs  or  actions 
between  the  user  and  tool  are  often  referred  to  as  transactions.  The  recording  of  the  user's 
interaction  with  the  tool  has  several  purposes.  It  can  be  used  by  the  tool  user  to  recall  how  a 
particular  task  was  accomplished,  or  to  estimate  how  long  the  task  took.  It  can  also  be  used  as 
a  means  of  tracking  the  mistakes  and  successes  of  a  subject  in  a  usability  study.  User  log^ng 
can  be  used  as  a  substitute  or  complement  to  other  means  of  observation,  such  as  videotaping  a 
subject  The  time  stamping  aspect  of  the  log  is  of  particular  importance  here.  User  logging  can 
also  sometimes  include  the  tti)^ty  to  play  back  the  user’s  interactions  and  watch  the  system 
responses. 

Evaluation  Questions: 

•  Did  the  tool  provide  any  user  log  generation  capability? 

•  Did  you  find  this  feature  useful? 

•  What  type  of  transactions  were  recorded? 

•  Where  and  in  what  format  was  the  data  saved? 

•  Does  the  format  of  the  recorded  data  support  the  use  of  data  analysis  tools? 

•  Were  the  transactions  time-stamped? 

•  Could  you  specify  the  types  of  events  to  be  logged  by  the  tool? 

2.3  USABILITY  ISSUES 
2.3.1  Graphic  Icons 

A  common  feature  of  both  Macintosh  and  IBM  PC  software  is  selectable  buttons 
labelled  with  pictures  instead  of  words.  These  graphic  icons  are  part  of  the  desktop  metaphor. 
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picturing  folders,  files,  mail,  and  trash  cans.  As  such  icons  become  more  ccanmon  to 
workstation-bas^  rapid  prototyping  tools,  however,  the  drawing  board,  the  desktop  of  the 
graphic  artist,  is  replacing  the  conventional  desktop.  The  drawing  board  metaphor  offers: 

•  Graphic  objects  including  primitives  such  as  lines,  arcs  and  circles  as  well  as  high- 
level  display  objects  such  as  selectable  butums,  scroll  bars,  and  pull-down  menus. 

•  Attributes,  including  color,  line  width,  font  style,  and  size. 

•  Operations  to  be  performed  on  the  (Ejects:  actions  such  as  move,  scale,  duplicate, 
and  delete. 

Evaluation  Questions: 

•  Does  the  tool  use  graphic  icons? 

•  Do  the  pictures  include  objects,  attributes,  and  operations? 

•  Do  you  find  these  pictures  easier  to  understand  than  words? 

2.3.2  Direct  Manipulation 

Physical  actions,  such  as  mouse  movement,  are  called  "direct  manipulations"  in  contrast 
to  entering  commands  on  a  keyboard  to  perform  a  huiction.  Direct  manipulation  uses  pointing 
input  devices  such  as  the  mouse,  track  ball,  or  joystick,  and  is  characterized  by  pick-and-click 
interfaces.  The  pointing  input  devices  operate  upon  lalreled  icons.  While  dir^  manipulation 
and  graphic  icons  seem  most  closely  interrelated,  text-labelled  icons  are  also  commonly  used  in 
a  diiwt  manipulation  environment 

Many  rapid  prototyping  tools  consist  of  subsystems  or  modules,  each  of  which  can 
have  a  different  interaction  tecbraque.  Evaluation  of  this  particular  criterion  may  therefore 
iq)ply  either  to  the  entire  tool,  or  to  modules  of  the  tool. 

Evaluation  Questions: 

•  Does  the  tool  use  direct  manipulation  techniques? 

•  What  pointing  device  did  you  use? 

•  Did  the  tool  allow  you  to  use  direct  manipulation  and  type  in  commands,  depending 
on  your  preference? 

2.3.3  Shallow  Menuing 

Some  tools'  menus  are  nested  only  one  or  two  layers  deep.  When  menuing  systems 
were  first  intro^ced,  tool  developers  found  that  deeply  nested  menus  could  provi^  hundreds 
of  options  at  once  and  allow  each  lower  level  of  menu  options  to  be  driven  by  the  user's  current 
menu  selection.  However,  as  nested  menus  became  more  popular,  tool  users  encountered 
several  disadvantages.  They  found  that  navigating  through  too  many  levels  of  menus  and 
choosing  from  among  too  many  options  can  be  a  cumbersome  and  confusing  process.  Even 
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with  the  use  of  pointing  input  devices  such  as  the  mouse  or  light  pen,  it  can  be  awkward  to 
navigate  through  a  large  number  of  options.  They  also  found  that  it  was  easy  to  get  lost  within 
the  nested  menus. 

For  these  reasons,  shallow  menuing  became  preferable.  As  a  rule  of  thumb,  menus 
should  not  be  more  than  two  or  three  layers  deep,  and  should  not  contain  more  than  ten 
q)tions.  One  of  the  most  popular  approaches  to  menu  “de-layering,”  which  was  adopted  by 
both  Apple  and  IBM  fOT  their  personal  computers,  is  use  of  menu  bars  (or  "action  bars"  in  EBM 
terminology)  that  allow  each  menu  to  be  attached  to  a  particular  menu  heading.  The  menu  bars, 
attached  to  the  top  or  bottom  of  the  screen,  permit  the  menu  options  to  be  separated  and 
categorized. 

Evaluation  Questions: 

•  Does  the  tool  have  a  menu-based  interface? 

•  If  so,  how  deeply  nested  are  the  menus? 

•  Approximately  how  many  options  are  included  in  each  menu? 

•  How  extensively  are  the  menus  used  in  the  interface? 

•  Are  menu  bars  used? 

•  Did  you  find  the  menuing  system  difficult  to  use? 

•  Were  command  alternatives  offered? 

2.3.4  Object  Placement 

Tools  can  be  distinguished  according  to  their  ability  to  arrange  display  objects 
accurately  and  precisely  on  the  screen.  It  can  be  a  tedious  process  to  arrange  text  or  other 
objects  along  a  horizontal  or  vertical  line.  F<x  example,  in  a  text-based  display,  it  may  be 
desirable  to  left-justify  all  the  text  along  a  vertical  line.  A  series  of  selectable  buttons  may  need 
to  be  aligiied  within  an  array,  or  perhaps  a  scroll  bar  must  be  placed  exactly  along  the  edge  of  a 
pop-up  window. 

For  applications  such  as  these,  an  object  placement  mecharusm  is  necessary.  The  most 
common  approach  is  to  use  a  grid  whose  rectan^e  size  can  usually  be  adjusted.  The  objects 
are  then  snapped  to  the  closest  grid  point.  A  more  advanced  approach  is  to  use  "precision 
points"  or  "sticky  points."  When  within  a  certain  radius  of  a  precision  point,  the  cursor  is 
drawn  towards  it  The  points  are  located  at  the  comers  and  sides  of  all  di^lay  objects  on  the 
screen,  making  it  easy  to  place  objects  next  to  each  other  pr^sely.  To  align  objects  along  a 
horizontal  or  vertical  line,  a  reference  line  with  its  own  precision  points  can  be  used. 

Evaluation  Questions: 

•  Did  the  tool  provide  any  technique  fOT  easy  object  placement? 

•  Did  the  object  placement  techiuques  provided  meet  the  needs  of  your  application? 
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2.3.5  Environment  Flexibility 

A  rapid  prototj^ing  tool  should  provide  a  flexible  development  environment  in  which 
the  tool  user  can  experiment  with  various  designs.  A  flexible  environment  is  one  in  which  the 
user  has  control  over  the  development  process.  For  example,  a  flexible  tool  does  not  constrain 
the  user  to  move  step-by-step  through  the  development  jmxxss  via  input  prompts,  nor  require 
that  a  prototype  be  developed  in  any  particular  ra^r.  With  a  flexible  tool,  the  user  can  biuld 
the  interface  displays  before  or  after  ^veloping  the  applicatirai  program,  assigning  dynamic 
behaviors  or  fui^txiality  to  the  display  objects  befrae  or  aiher  ttey  are  referenced  in  the 
tqiplicatitxi  program.  Display  objects  can  be  created  in  any  ratler.  The  carder  in  which  they  are 
created  does  not  restrict  their  placement  in  front  or  in  back  of  other  objects. 

The  degree  of  flexibility  needed  in  a  rapid  prototyping  system  is  driven  by  the 
developer's  mental  model.  In  software  development,  a  mentd  model  is  charactenzed  by  the 
thought  process  or  frame  of  reference  of  the  designer(s)  and/or  developerfs).  For  example,  a 
software  engineer,  human  factors  engineer,  and  the  user  can  all  have  deferent  mental  models  of 
the  same  software  tool.  The  software  engineer  may  want  to  develop  in  a  way  that  reduces  the 
amount  of  coding  and/or  (^timizes  the  performance.  The  human  factors  engineer  may  wish  to 
make  the  software  as  usable  as  possible.  The  user  may  want  all  kinds  of  fancy  features  and 
colors.  These  are  three  mental  models:  the  programmer  model,  the  designer  model,  and  the 
user  model  If  the  programmer's  model  dominates  during  system  design,  the  system  may  be 
inflexible  but  have  go^  performance.  If  the  human  factors  engineer's  model  dominates,  the 
system  may  be  easy  to  use  but  difficult  to  implement  If  the  user's  model  dominates,  the 
software  may  be  flexible  but  slow.  The  goal  is  to  find  the  optimal  balance  between  Aese  three 
models. 

A  flexible  prototyping  environment  gives  the  user  a  great  deal  of  fireedtHn.  However,  it 
also  gives  him  the  freedom  to  make  mistakes.  Inherent  in  this  model  is  the  responsibility  to 
remember  development  and  modification  details.  For  this  reason,  it  is  a  good  idea  to  couple 
flexibility  with  an  intuitive  and  simple  interface.  This  combination  can  make  the  task  of 
prototype  development  a  creative  and  enjoyable  experience  rather  than  an  overwhelming  task. 

Evaluation  Questions: 

•  Do  you  feel  that  you  were  in  control  of  the  development  process  with  this  tool? 

•  Can  you  build  your  prototype  components  in  any  order  you  wish? 

2.3.6  Screen  Overview 

A  variety  of  features  allow  the  tool  user  to  view  the  complete  screen.  A  screen 
overview  function  is  helpful  when  the  user  is  panning,  zooming,  or  working  with  only  one 
object  at  a  time.  When  using  these  capabilities,  it  is  easy  to  become  "lost"  within  the  display. 
For  example,  the  graphics  edtor  of  a  tool  may  provide  a  “drawing  space"  that  is  bigger  than  the 
view  window  through  which  the  user  works.  The  user  may  need  to  pan  around  the  “drawing 
space”  to  create  a  complete  display.  In  some  graphics  editors,  selection  of  a  single  object 
within  a  display  can  cause  the  remainder  of  the  drawing  to  disappear  from  the  screen. 
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The  most  common  method  of  implementing  a  screen  overview  is  the  inset,  usually  a 
small  rectangle  showing  a  picture  of  the  complete  screen.  The  overview  inset  can  appear 
anywhere  (hi  the  screen,  but  is  most  often  pkuted  at  one  of  the  four  comers.  Among  other 
implementations  of  the  screen  overview  concept  is  the  fish-eye  view  in  which  the  area  of 
interest  is  surrounded  by  progressively  less  detailed  representations  of  the  rest  of  the  screen. 
The  area  of  interest  may  be  a  zoomed  (h-  panned  secticHi,  or  a  particular  object  The  fish-eye 
view  is  a  bit  trickier  to  implement  and  perhaps  more  difficult  to  use  than  standard  views,  but 
may  become  more  widely  used  in  dme. 

Evaluation  Questions: 

•  Does  the  teol  have  a  screen  overview  capability? 

•  If  not  did  you  feel  the  need  for  a  screen  overview  capability  while  using  it? 

•  Did  you  feel  that  getting  lost  within  the  complete  display  was  a  problem? 

2.3.7  Response  Time 

In  interacdve  c(xnputer  systems  that  provide  on-line  ctnnmunication  between  the  user 
and  the  system,  the  resptmse  time  is  the  time  delay  between  when  the  user  submits  a  request 
and  when  the  system  responds.  In  rapid  prototyping,  the  response  dme  is  Ae  time  delay 
between  manipulating  an  interactive  object  and  occurrence  of  the  specified  fimction.  Fen* 
example,  if  a  button  (hi  the  screen  is  responsible  for  bringing  up  a  pop-up  window,  the 
response  time  is  the  time  delay  between  the  user  selecting  the  button  and  the  pop-up  window 
apj^aring  on  the  screen.  Or  the  response  time  may  be  the  time  delay  involved  in  sequencing 
from  one  display  within  the  interface  to  the  next  In  this  case,  it  is  the  time  taken  for  the  current 
display  to  disappear  and  the  new  one  to  appear. 

A  prototype's  response  time  is  affected  by  the  "overhead"  of  a  particular  tex)!,  the 
amount  of  processing  and  storage  space  the  Kxrl  requires.  The  response  time  of  a  prototype 
built  with  a  tool  will  also  be  affected  by  the  complexity  of  the  prototype.  Excessive  oveiliead 
requirements  can  decrease  a  tool's  performance,  yet  it  is  often  a  characteristic  of  powerful, 
easy-to-use  Kmls.  For  example,  a  t(X)l  that  requires  no  programming  or  only  sm^  amounts  of 
high-level  progranuning  will  often  require  a  great  deal  of  overheatL  A  balance  between  power 
and  performance  must  therefore  be  achieved  fai  some  circumstances,  code  optimization  by 
both  the  t(X)l  developer  and  the  t(X)l  user  can  be  helpful  in  reaching  this  balance. 

Evaluation  Questions: 

•  How  do  you  rate  the  tcral's  performance? 

•  How  do  you  rate  the  performance  of  an  ^plication  built  with  the  t(X)l? 

•  Does  the  t(X)l  provide  response  time  similar  to  what  would  be  required  in  a  real 
application 

2.3.8  Confirmation  Checks 

A  great  deal  of  work  and  time  can  be  lost  due  to  accidental  deletion  of  a  file  (h*  failure  to 
save  recent  work;  for  example,  when  a  user  quits  the  system  without  saving.  Confirmation 
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checks  avoid  disastrous  situations  such  as  these  by  making  the  user  rethink  his/her  action. 

They  usually  take  the  following  forms:  "Are  you  sure  you  want  to  delete  the  file?  Are  you  sure 
you  want  to  overwrite  the  file?  Are  you  sure  you  want  to  close  the  file  without  saving?  Are 
you  sure  you  want  to  end  this  session?"  Although  overuse  of  such  checks  can  be  annoying  to 
the  expert  user,  a  reasonable  number  of  them  can  be  helpful  to  both  the  novice  and  expen  user. 

Evaluation  Questions: 

•  Does  the  tool  provide  confirmation  checks  at  potentially  hazardous  actions  e.g., 
delete  flle,  quit  without  saving? 

•  Are  they  placed  at  critical  points? 

•  What  are  some  examples  of  confirmation  checks  within  the  tool? 

2.3.9  File  Recovery 

File  recovery  is  related  to  the  idea  of  confirmation  checks.  While  confirmation  checks 
are  used  to  prevent  disastrous  situations,  file  recovery  is  aimed  at  enabling  the  user  to  recover 
firom  such  a  situation.  Many  examples  of  file  recovery  techruques  can  be  found  in  new  and  old 
computing  envirtmments.  For  example,  in  the  TOPS  20  qierating  system,  a  deleted  file  is 
available  for  restoration  until  the  user  issues  the  "expunge"  command.  In  ^e  VAX/VMS 
environment,  saving  a  new  version  of  a  file  will  also  cause  a  backup  version  of  the  original  file 
to  be  generated.  A  third  example,  c(»nmon  to  many  user  interface  tools,  is  the  “undo” 
command.  This  command  allows  the  user  to  negate  the  last  commaixL  Unfortunately,  in  many 
software  tools,  "undo"  does  not  apply  to  the  us^s  response  to  a  confirmation  check.  In 
general,  a  r^id  prototyping  software  tool  is  said  to  provide  file  recovery  if  there  is  some 
tcchruque  provided  to  automatically  back  up  or  restore  the  prototype  once  it  is  deleted  or 
modified. 

Evaluation  Questions: 

•  Does  the  tool  supply  any  techniques  for  file  recovery? 

•  If  so,  when  a  file  is  restored,  is  it  in  its  original  format? 

•  Does  the  tool  provide  an  "undo"  capability? 

2.3.10  Development  Without  Coding 

There  are  two  separate  issues  to  be  considered  within  this  criterion:  development  of  the 
“look”  of  the  prototype,  and  development  of  its  “feel.”  At  a  minimum,  a  rapid  prototyping  tool 
should  allow  the  user  to  develop  the  "look"  of  the  interface,  including  the  object  colors, 
attributes,  and  placement,  without  programming.  This  is  often  accomplished  through  a 
graphics  editor  with  which  the  tool  user  can  create  the  prototype  displays  via  a  pick-and-click 
interface  or  a  menuing  system.  Such  design  flexibility  in  the  ^velopment  environment  is  an 
important  aspect  of  rapid  prototyping. 

The  “feel”  of  the  prototype,  on  the  other  hand,  which  involves  assigning  behavioral 
characteristics  to  the  objects  and  defining  the  sequencing  of  the  displays,  is  commonly 
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develq)ed  Arough  programming.  Therefore,  it  is  a  noteworthy  characteristic  if  a  tool  allows 
the  functioning  of  a  prototype  to  be  developed  without  coding. 

A  development  envircxunent  that  does  not  require  programming  has  several  advantages. 
Rrst,  it  can  make  the  task  of  building  a  prototype  simpler  and  less  time-consuming.  Sectmd,  it 
can  l^ome  a  flexible  envircMunent  by  eliminating  the  need  for  programming  changes  when 
modifying  the  prototype.  Ifowever,  it  can  also  be  a  hindrance  to  the  develq)ment  process  for 
an  expert  software  engineer,  who  would  like  to  type  programming  commands.  In  addition,  it 
may  ^so  limit  the  range  of  behaviors  that  can  be  assign^  to  objects. 

Evaluation  Questions: 

•  Could  you  specify  the  “look”  of  the  user  interface  without  coding? 

•  Could  you  specify  the  "feel"  of  the  prototype  without  coding? 

•  If  not,  what  was  the  alternative  approach? 

2.3.11  Novice  Versus  Expert  User  Support 

Rq)id  prototyping  tools  are  used  by  a  diverse  community  of  software  engineers, 
graphic  artists,  human  factors  engineers,  and  others.  This  diverse  population  has  a  range  of 
skills,  from  users  proficient  with  the  tool  to  beginners.  Rapid  prototyping  tools  should 
therefore  be  capable  of  supporting  both  the  novice  and  the  expen  user. 

The  commtxi  tqiproach  to  this  problon  is  U>  supply  two  types  of  interfaces  for  prototype 
development  Fbr  example,  a  tool  may  provide  both  a  pick-and-click  interface  and  a  command 
language  to  support  display  generation.  The  pick-and-click  interface  is  often  helpful  to  novice 
users,  while  the  expen  user  may  find  it  cumbersome  and  inhibiting  and  prefer  to  type  in 
commands.  To  suppon  both  types  of  users,  a  rapid  prototyping  tool  is  preferable  if  it  supplies 
both  types  of  interfaces. 

Evaluation  Questions: 

•  Did  the  tool  supply  more  than  oat  method  of  user  interaction? 

•  Did  the  tool  provide  an  easy  mechanism  for  using  a  combination  of  interface  styles 
(e.g.,  menuing,  pick-and-click)? 

2.3.12  Learning  Curve 

One  of  the  most  critical  criteria  for  rapid  prototyping  is  the  learning  curve.  The  purpose 
of  rapid  prototyping  software  tools  is  to  simplify  and  streamline  the  prototyping  process, 
quicldy  producing  a  visual  example  of  how  the  system  wiU  appear  and  function.  It  is  therefore 
important  for  a  rapid  prototyping  tool  to  be  relatively  easy  to  use.  Learning  to  use  it  should  not 
require  a  great  deal  of  time.  An  unexpectedly  steep  learning  curve  can  drain  funds  and  hamper 
ps^uctivity. 

Many  different  factors  can  affect  a  tool's  learning  curve.  The  quality  of  its  user 
interface  can  be  a  major  factor.  The  interface  should  be  as  simple,  straightforward  and  intuitive 
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as  possible.  The  amount  of  coding  requiied  in  the  develq)ment  process  can  also  be  a  factor. 
POw  documentation  can  be  a  source  of  frustratitm.  A  training  course  can  be  helpful  and 
significandy  reduce  training  time. 

The  learning  curve  is  an  area  in  which  many  of  the  rapid  prototyping  tools  on  the 
market  today  need  to  improve.  The  problem  stems  firom  a  to  balance  power  with 
simplicity.  The  tools  must  be  powe^  enough  to  provide  an  array  of  gn^hic  objects  and 
functional  behaviors.  Yet  they  must  be  simple  enou{^  to  allow  the  user  to  produce  a  prototype 
rapidly.  The  difficulty  of  balancing  titese  two  goals  (tfien  produces  a  tool  that  does  not  provide 
the  high-level  display  objects,  such  as  scroll  bars  and  pull-down  menus,  or  requires  two  or 
tinee  months  to  team.  The  qrtimal  balance  between  power  and  simplicity  is  iixteed  an 
important  and  challenging  gc^ 

Evaluation  Questions: 

•  Was  the  tool  easy  or  difficult  to  learn  to  use? 

•  Ifow  long  would  you  estimate  it  took  you  to  become  proficient  with  the  tool? 

•  Did  you  attend  a  training  course  fOT  the  tool? 

•  If  so,  do  you  feel  the  course  reduced  your  learning  curve? 

2.3.13  Usable  Documentation 

As  many  software  tool  users  will  attest,  the  quality  and  the  ctmtent  of  tiie  documentatitm 
can  have  a  signfficant  effect  upon  a  tool's  general  usability.  The  term  "usability,"  which  is 
most  often  ^plied  to  a  software  system,  is  just  as  important  when  ^plied  to  the 
documentation.  This  is  especially  true  for  more  complex  software  tools,  such  as  r^id 
prototyping  packages. 

Documentation  should  be  complete,  clearly  written,  well-organized,  and  above  all 
accurate.  A  documentation  set  should  include  a  "How  To  Get  Star^"  tutorial  and  a  tool 
overview  as  well  as  system,  user,  and  progrwmer  guides  and  reference  manuals.  Each  new 
version  of  the  software  should  be  accompai^  by  an  updated  set  of  documentation.  In 
addititm,  a  newsletter  discussing  recently  discovered  software  bugs  and  ways  to  avoid  them 
can  be  helpful. 

Evaluation  Questions: 

•  What  types  of  documentaticm  provided? 

•  What  is  your  general  impression  of  the  tool's  documentation? 

•  Did  die  tool  features  perform  as  advertised? 

•  Did  you  find  some  software  bugs  in  the  tool? 

•  Did  the  vendor  make  you  aware  of  any  bugs  in  the  tool? 
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2.4  VENDOR  SUPPORT  ISSUES 

2.4.1  Installation  Assistance 

A  repr^ntadve  the  company  that  develq)s  and/or  distributes  the  nq)id  prototyping 
tool  may  be  willing  to  visit  your  fa^ty  to  assist  in  installation.  If  possible,  it  is  helpful  to  have 
both  a  technical  and  a  marketing  representative  in  attendance.  This  will  help  you  to  begin  using 
the  tod  as  well  as  establish  a  basis  for  future  support 

Evaluation  Questions: 

•  Did  the  tool  representatives  visit  your  facility  to  assist  in  the  installation  procedure? 

•  What  was  the  cost  of  these  services? 

•  What  type  of  assistance  did  they  provide? 

•  Were  they  technically  capable? 

2.4.2  Evaluation  Period 

Vendor  support  can  also  include  the  opportunity  to  obtain  a  tool  for  a  trial  evaluation 
period.  Evaluation  periods  allow  the  tool  user  to  evaluate  which  tool  will  best  suit  a  particular 
application's  needs.  They  are  typically  limited  to  a  90  day  duration,  but  can  be  extended  in 
extenuating  circumstances. 

Evaluation  Questions: 

•  Were  you  able  to  obtain  the  tool  for  a  free  evaluation  period? 

•  How  long  was  the  evaluation  period? 

•  Were  there  any  difficulties  in  getting  the  tool  to  run? 

2.4.3  Training 

The  tool  vendor  may  be  willing  to  provide  a  few  days  or  a  week  of  training,  at  either  the 
vendor's  or  the  user’s  facility.  The  location  of  the  training  can  often  depend  on  the  number  of 
people  to  be  trained  and  on  hardware  platform  availability. 

The  costs  and  benefits  of  a  training  program  must  be  weighed  in  advance;  this  is  a 
difficult  task.  There  ate  sev^  factors  to  consider.  First,  the  vendor  may  agree  to  reduce  the 
price  of  trairung  per  perstxi  if  there  are  many  trainees,  or  if  more  than  one  cc^y  of  the  tool  will 
be  purchased.  Secondly,  the  most  effective  courses  usually  require  a  trainer(s)  with  experience 
in  botii  education  and  software  engineering.  Courses  that  ^vide  the  course  time  evenly 
between  classroom  lectures  and  "hands-on"  assignments  are  helpful. 

The  answers  to  the  above  issues  wUl  assist  the  user  in  deciding  whether  to  purchase  a 
trairung  period.  As  noted  above,  it  is  also  useful  to  obtain  the  tool  for  a  trial  evaluatitm  period 
to  assess  its  difficulty  before  making  a  purchase  decision. 
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Evaluation  Questions: 

•  Did  you  receive  any  formal  training  from  the  tool  vendw? 

•  Did  the  course  mix  class  lectures  with  "hands-on"  assignments? 

•  How  long  was  the  training  course? 

•  Did  it  cover  the  features  you  needed  for  your  application? 

•  Was  the  course  tailored  to  your  needs? 

•  Ifow  long  did  it  take  you  to  become  proficient  with  the  tool? 

2.4.4  Telephone  Assistance 

The  quality  of  telephone  sui^xxt  for  a  tool  can  be  critical  for  a  smooth  and  successful 
prototype  development  Indeed,  assistance  via  telephone  may  be  the  most  important  aspect  of 
vendor  support  Evaluation,  installation,  and  training  support  take  place  at  the  beginning  of  the 
process  of  using  a  tool;  after  they  are  completed,  the  telephone  will  probably  be  £e  sole  source 
of  vendor  support  It  is  therefore  important  that  technictd  representatives  be  available  for 
telephone  siqtport  It  is  particularly  helpful  if  a  west-coast  vendor  has  technical  support 
representatives  located  on  the  east  coast  and  vice-versa.  Hours  of  "telephone  tag"  can  cause 
long  delays  in  prototype  development  Finally,  tite  telephtme  representatives  should  be  fully 
vei^  in  the  history  and  technical  details  of  the  tool.  V^en  they  do  not  immediately  know  the 
answer  to  a  question,  they  should  be  willing  to  lot^  into  it  and  return  the  call  later. 

Evaluation  Questions: 

•  Did  the  tool  vendor  supply  you  with  prompt  telephone  support? 

•  Were  there  people  specifically  assigned  to  full-time  technical  support? 

•  Was  it  difficult  to  get  sometme  available  to  help  you? 

•  Was  help  available  during  your  work  hours? 

•  Did  they  provide  an  (800)  phone  number? 

•  Did  they  provide  electronic  mail  access? 

•  Were  they  able  to  solve  your  problems? 

2.5  SOFTWARE  ISSUES 
2.5.1  Standards  Compatibility 

To  support  the  goals  of  portability  and  compatibility  with  other  tools,  rapid  prototyping 
tools  should  adhere  to  die  emeipng  industry  standards  such  as  distributed  windows,  dialogue 
style  (e.g..  Motif  or  Open  Look),  and  communications  protocol. 

Evaluation  Questions: 

•  Does  the  tool  adhere  to  any  current  industry  standards? 
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•  If  so,  which  ones? 

2.5.2  Open  Architecture 

Many  n^d  prototyping  tools  on  the  market  address  a  variety  of  applicatitms.  Their 
features  often  complement  one  another.  For  example,  tme  tool  may  supp^  develt^ment  of  a 
user  interface,  anodier  may  be  a  mapping  display  system,  and  a  third  may  be  a  knowledge- 
based  hypertext  tool.  It  is  helpful  if  these  tools  have  open  architectures  so  they  can  be  easily 
integrate  and  used  t^ether.  Tools  with  open  architectures  can  accept  the  output  finom  another 
tool  as  input,  or  provi^  output  to  another,  enabling  the  user  to  put  an  array  of  tools  to  work  on 
an  interface  problem. 

Evaluation  Questions: 

•  Did  the  tool  have  an  open  architecture? 

•  Did  it  accept  output  from  another  tool? 

•  If  so,  in  what  format? 

Preference  Questions: 

•  What  types  of  tools  would  you  want  to  use  with  it? 

2.6  HARDWARE  ISSUES 

2.6.1  Portability 

Portability  can  be  an  important  factor  for  many  applications.  Not  all  prototypes  are 
"throwaway”  software  projects.  Many  user  interface  prototypes  are  develt^)^  as  a  "proof  of 
concept"  for  a  system  and  then  expanded  into  an  actual  system.  And  if  the  target  hardware 
platform  is  not  really  available  in  the  design  phase,  portabilipr  can  become  an  important  issue. 
As  hardware  technology  continues  to  evolve,  system  portability  becomes  even  more  of  a 
challenge  and  a  necessity. 

Evaluation  Questions: 

•  Does  the  tool  enable  you  to  develop  a  portable  prototype? 

•  On  what  hardware  platform  can  you  build  the  prototype? 

•  To  what  hardware  platfoms  can  you  port  the  prototype? 

•  Did  the  tool  provide  a  run-time  version? 

2.6.2  Multiple  Display  Devices 

As  distributed  systems  become  mcxe  common,  it  is  impmant  that  rapid  prototyping 
tools  be  able  to  support  m<xe  than  one  display  device  at  a  time. 
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Evaluation  Questions: 

•  Can  the  tool  support  multiple  display  devices? 

•  If  so,  how  many  and  what  types? 

2.6.3  Multiple  Input  Devices 

Rapid  prototyping  tools  should  be  able  m  handle  input  6om  multiple  devices  at  one 
time.  In  action,  they  should  be  able  to  accept  input  fh>m  a  variety  of  input  devices,  such  as 
the  keyboard,  mouse,  or  track  ball. 

Evaluation  Questions: 

•  Can  the  tool  handle  more  than  one  input  device? 

•  If  so,  what  type? 
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SECTION  THREE 
TOOL  REVIEWS 


3.1.  INTRODUCTION 

This  section  contains  the  HFE/USI  Group's  evaluatitm  results  for  the  following  USI  rapid 
protoQ^ing  tools:  VAPS,  LUIS/SMS,  S^GMS,  Data  Views,  TAE  Plus,  SET.  Induct  for  each 
tool  is  an  overview  description  of  the  basic  software  components,  prototype  develq)ment  steps, 
implications,  hardware  pk^orms  and  cost  (site  license  costs  are  negotiable  for  all  tools).  The 
evaluation  results  for  each  tool  then  follow.  The  five  criteria  categories  introduced  in  section  2 
(capabili^,  usability,  vendor  support,  hardware,  and  software  issues)  are  addressed  for  each  tool. 
The  criteria  the  tool  directly  supp^,  or  which  it  can  support  with  additional  effort  by  the  user 
interface  develop^,  are  discuss^  The  evaluatitm  results  are  summarized  in  a  set  of  'Tools-At- 
A-Glance"  tables  in  the  appendix. 

3.2.  VAPS 

3.2.1  Overview 

The  VAPS  Prototyping  System  is  a  high-end  USI  rapid  prototyping  tool.  VAPS 
provides  a  flexible  prototyj^g  environment  in  which  the  user  interface  can  be  modified  quickly 
and  easily.  VAPS  is  a  product  of  Virtual  Prototypes,  Inc.  of  Montreal,  Canada.  Version  2.0S 
is  the  most  recent  version  of  VAPS  and  is  discuss^  here.  VAPS  originally  ran  only  mi  Silicon 
Graphics  woricstations,  but  it  now  runs  on  other  platfmms,  including  Sun  and  IBM  (and  soon 
HP)  workstations.  Its  cost  ranges  from  $15,000  to  $41,0()0,  depen^g  on  the  configuration. 

Althou^  VAPS  was  originally  developed  to  support  avimiics  applications,  it  can  also 
be  used  to  support  a  range  of  user  interface  applications.  It  is  particularly  useful  for 
prototyping  ht^ware  devices  such  as  equipment  and  display  consoles.  Version  1.04  has  been 
used  successfully  to  prototype  control  ps^ls  and  transceivers  for  a  tactical  system,  command 
center  displays,  instrumentation  panels,  tactical  ra^o  panels,  and  aircraft  cockpits.  Version 
2.05  has  been  enhanced  to  accommodate  advanced  graphics  symbology  for  C3I  and  air  traffic 
control. 

The  VAPS  Prototyping  System  consists  of  four  software  subsystems  that  collectively 
provide  all  the  capabilities  neoM  to  quickly  implement  a  user  interface.  The  subsystems 
include  the  object  editor  (also  known  as  the  graphics  editor),  integration  editm:,  logic  editm, 
and  runtime  environment 

3.2.2  Object  Editor 

The  object  editOT  provides  an  extensive  set  of  drawing  tools,  including  precision 
drawing  aids  and  overlay  templates,  and  can  be  used  to  create  prototype  displays,  or  in  VAPS 
terms,  "frames,"  and  the  graphic  objects  that  comprise  the  frames.  C^phic  objects  can  be 
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precisely  placed  within  the  frames  via  a  pointing  device.  The  overlay  templates  permit  a  portion 
of  a  prototype  frame  to  be  updated  or  redrawn,  decreasing  response  time. 

To  create  the  frames,  the  object  editor  supplies  a  variety  of  graphics  primitives, 
attributes,  and  ope^tms.  llie  VAPS  primitives  include  diagonal  l^s,  horizcmtal  and  vertical 
lines,  rectangles,  circles,  arcs,  filled  arcs,  spline  curves,  filled  splines,  text,  and  filled 
polygons.  There  are  four  attributes:  color,  texture,  line  style,  and  font  style.  The  operations 
tiiat  can  be  performed  upon  the  objects  include  moving,  rotating,  scaling,  duplicating,  copying, 
^licating  at  an  an^e,  deleting,  comer  rounding,  and  undoing  tiie  previous  action.  An  object 
is  created  by  selecting  and  grouping  a  set  of  primitives. 

The  object  editor  also  allows  the  user  to  assign  behavioral  characteristics  to  gn^hic 
objects  through  values  such  as  mirtimum  and  maximum,  lines  of  motion,  and  center  of 
rotation.  There  are  three  basic  types  of  behavioral  models  for  VAPS  objects:  display  objects, 
input  ob^ts,  and  output  objects.  A  display  object  is  non-interactive.  Input  objects  are  objects 
with  which  the  end  user  can  directly  interact  There  are  several  different  kinds  of  input  objects. 

•  The  button  object  is  multi-state  and  can  take  on  a  different  graphic  representation 
based  on  its  state.  For  example,  a  light  can  be  in  an  "on"  or  "off'  state.  A  button's 
state  might  represent  one  of  several  colors,  changing,  for  example,  among  red, 
yellow  and  gimn  based  on  three  states. 

•  Switches  are  similar  to  buttons,  except  tiiat  each  state  of  the  switch  is  represented  by  a 
different  part  of  the  screen,  while  butmn  states  are  represent«l  by  chants  in  color  or 
other  attributes  at  the  same  position  on  the  screen. 

•  A  rotor  is  an  input  object  that  generates  discrete  numerical  values  based  on  its 
rotational  position. 

•  A  knob  is  similar  to  a  rotOT,  except  that  the  knob  generates  continuous  rather  than 
discrete  data  values. 

•  A  potentitnneter  generates  data  values  based  on  its  linear  position. 

•  An  event  object  signals  the  occurrence  of  an  event  When  selected  at  runtime,  it 
sends  a  code  back  to  an  application  system  indicating  that  a  specific  event  has  occurred. 

There  are  also  several  different  output  objects,  which  can  be  driven  by  the  application 
system  or  directly  by  input  objects. 

•  A  light  is  a  multi-state  output  object  that  can  take  on  different  graphic 
representations  based  on  state  values  received  as  input. 

•  A  dial  rotates  based  on  input  values. 

•  A  scale  moves  linearly . 
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•  A  tape  moves  behind  a  defined  window  so  that  only  the  part  of  the  tape  inside 
the  tounds  of  the  window  is  visible. 

•  A  dial  moves  both  rotatitmally  and  lineaily. 

•  A  barchart  extends  and  contracts  between  a  maximum  and  minimum  value. 

New  objects  added  in  version  2.05  include: 

•  A  plan  position  indicator  for  radar  and  sonar. 

•  A  graph  object  for  charts  and  graphs. 

•  A  menu  object  for  pull-down  and  pq>-up  graphical  menus. 

•  A  locater  for  simulating  2D  input  devices. 

•  A  CRT  objea  for  multiple  nested  virtual  CRT  displays. 

Other  characteristics  of  the  object  editor  include  an  “infinite"  drawing  space,  an  overlay 
plane  for  references,  and  "precision  p^ts"  for  object  placement  References  are  objects  that 
i^pear  on  the  screen  to  assist  with  object  placement  but  which  are  not  saved  as  pan  of  the 
fnme. 

3.2.3  Integration  Editor 

After  creating  the  gr^^)hic  objem,  the  next  step  is  to  connect  the  output  objects  to  the 
input  that  will  drive  their  behavior  during  runtime.  This  is  accomplished  within  the  integraticMi 
ettitor.  Output  objects  can  be  driven  by  input  objects,  by  internal  VAPS-supplied  functions 
such  as  sine,  triangular,  and  ramp  fimctions,  or  by  external  simulation.  The  integration  editor 
creates  visutd  representations  for  the  input  and  ouput  plugs.  Using  these  representations, 
ouq)ut  objects  are  "connected"  to  whatevo'  input  wtil  dive  them.  Input  objects  are  consittered 
internal  ^vers,  while  VAPS-st^plied  functions  and  simulation  values  are  external 
Additionally,  die  integration  editor  provides  a  feature  to  combine  various  input  data  through 
mathematical  or  Boolean  functions. 

3.2.4  Logic  Editor 

The  third  step  in  user  interface  development  is  accomplished  in  the  logic  editor,  which 
enables  the  user  to  specify  and  control  the  dialog  with  the  prototype.  It  automatically  generates 
code  based  cm  the  ft^es,  objects  and  ccmnecticms  established  in  the  object  editcr  and  the 
integration  editor.  In  VAPS,  just  as  the  objects  themselves  can  have  a  number  of  states,  the 
user  interface  as  a  whole  is  alM  based  upcm  a  tinite-state  machine  mcxleL  This  means  that  the 
user  interface  can  transition  between  different  states,  for  each  of  which  a  number  of  events  are 
considered  active  or  "executable.”  VAPS  considers  each  new  frame  within  an  interface  a 
unique  state. 
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The  code  generated  by  the  logic  editor.  Augmented  Transition  Network  (ATN),  is  a 
high-level  grapl^  interface  lan^ge  similar  to  the  C  lan^age.  In  fact,  C  code  can  be 
embedded  within  ATN,  and  during  compilation  the  ATN  is  translated  to  C  code. 

Using  ATN,  the  developer  defines  those  events  which  are  active  or  inactive  within  each 
state.  VAPS  provides  a  programming  library  of  over  100  routines  that  can  be  called  inside  the 
ATN  to  perform  actions,  such  as  hig&ghting  objects,  moving  objects  dynamically,  changing 
(^ject  attributes,  and  reading  text  input  fields.  Tte  only  difficulty  in  using  the  logic  editor  is  in 
planning  and  understanding  the  user  interface  dialog.  A  good  approach,  and  one  that  is 
stressed  in  the  VAPS  training  course,  is  always  to  draw  a  state  diagram  before  beginning  to 
modify  the  ATN. 

3.2.5  Prototype  Development  Steps 

The  steps  for  building  implications  using  VAPS  include: 

•  Designing  the  frames  that  will  make  up  the  prototype 

•  Creating  the  frames  and  objects  within  the  object  editor 

•  Connecting  dynamic  objects  to  their  appropriate  drivers  within  the  integration  editor 

•  Designing  a  state  machine  model  of  user  interface 

•  Generating  and  modifying  the  ATN  within  the  logic  editor 

The  display  manager  handles  the  runtime  activities.  After  running  the  prototype,  it  may  be 
necessary  to  return  to  the  object  editor,  the  integration  editor,  or  the  lo^c  editor  to  make 
modifications.  It  is  very  easy  to  quickly  modify  any  aspect  of  the  interface  until  it  functions  as 
desired. 

3.2.6  Evaluation 

Capabilities 

VAPS  supports  development  of  vector-drawn  geographical  maps,  but  a  custom  data 
format  may  be  necessary.  VAK  directly  supports  the  WmM  Database  I  and  n  and  Defense 
Mapping  A^ncy  Digital  Terrain  Elevation  Data  (DMA  DTED)  formats.  It  also  allows  easy 
zDonung  and  panning  of  mtm^  and  other  graphic  objects.  Toggle  overlays  for  mapping 
applications  can  be  defined  within  VAPS  by  assigning  visibility  attributes  to  sections  of  the 
map. 


VAPS  supports  both  alphanumeric  and  picture  labels  on  display  objects.  It  is  also 
possible  to  create  fcxmatted  text  input  fields,  but  that  type  of  interaction  is  not  a  major  emphasis 
of  VAPS.  The  same  is  true  for  creating  objects  that  flash  or  reverse  video:  it  can  be  done  with 
VAPS,  but  it  is  not  easy.  For  example,  to  create  a  flashing  object,  two  states  must  be  defined, 
the  normal  or  "non-flash”  appearance  and  the  "flash"  appearance.  To  toggle  between  the  two 
states,  the  object  must  be  connected  to  some  type  of  input  function,  such  as  a  sine  wave.  When 
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the  value  of  the  driving  function  is  between  1  and  2,  the  object's  graphical  representation  for 
state  1  is  displayed;  when  the  value  is  between  2  and  3,  the  state  2  representation  is  displayed 

VAPS  supports  a  vaiieQr  of  input  and  ouqjut  objects,  but  they  are  usually  created  from 
primitives  within  Ae  reject  editor,  unless  the  user  first  creates  an  object  library.  The  palette  of 
primitives  that  are  directly  supported  includes  circles,  arcs,  ovals,  and  rectangles.  These 
primitives  can  be  used  to  create  the  higher  level  objects  such  as  potentiometers,  dials,  and 
knobs. 

VAPS  generates  Augmented  Transition  Network  (ATN)  code  that  can  be  modified 
within  the  logic  editor.  The  system  also  provides  a  library  of  many  graphic  interface  routines  to 
perform  hi|^-level  fimctions.  ATN  is  bt^ed  on  a  state  diagram  that  de^es  the  flow  of  control 
for  the  program,  and  it  must  be  modified  by  the  developer  to  tailor  it  to  the  particular  prototype. 
Strai^t  C  code  can  be  embedded  within  iL 

Usability 

The  object  editor,  integration  editor,  and  logic  editor  of  VAPS  all  allow  the  develq)er  to 
build  a  prototype  by  directly  marupulating  graphic  icons.  For  example,  the  graphic  primitives 
available  witHm  the  object  ^tor  are  all  arranged  on  a  palette.  The  develq:^  can  simply  select 
and  drag  the  graphics  to  any  location  on  the  frame.  VAPS  also  provides  single-layer  menu  bars 
to  handle  such  operations  as  grouping  objects,  placing  objects  in  front  or  back  of  other  objects, 
and  saving  a  model  It  also  provides  a  tailorable  interface  within  which  the  developer  can 
spedfy  which  menus  are  available  at  any  given  time. 

VAPS  also  has  a  unique  and  useful  feature  that  allows  precise  placement  of  an  object  on 
a  frame,  called  "precision  points."  These  points  exist  on  the  comers  of  every  object.  As  the 
mouse  cursor  moves  closer  to  the  precision  points,  there  is  a  slight  pull  on  the  mouse  towards 
them.  Once  the  cursor  is  within  an  object’s  precision  point,  it  can  be  placed  directly  on  top  of 
the  point  of  another  t^ject,  causing  the  objects  to  be  placed  precisely  next  to  each  other.  This 
can  be  an  extremely  use^l  design  feature.  For  example,  without  precise  object  placement,  it 
can  be  difficult  and  time-consuming  to  porfectly  align  the  objects  when  creating  a  button  palette. 
Precision  points  make  it  easy. 

The  VAPS  envirtmment  for  user  interface  develt^ment  is  flexible.  VAPS  is  a  powerful 
tool  and  can  support  the  development  of  complex  prototypes.  However,  it  does  ^uire  a  great 
deal  of  overhead  which  can  affect  runtime  performance.  Therefore,  when  building  a  prou>type 
with  VAPS,  it  is  important  to  keep  optimization  and  performance  in  mind.  VAPS  is  n(H  ovetiy 
difficult  to  leam  to  use.  It  provides  a  large  number  of  confirmation  checks.  The  documentation 
is  Iwlpfril.  In  aMtion,  VAPS  has  a  automatic  "save”  feature  that  can  be  set  at  different  time 
intervals  so  tiiat  a  prototype  under  development  can  be  periodically  saved.  Some  limitations  are 
presented  by  the  system's  somewhat  clos^  architecture,  in  that  it  is  limited  to  a  particular 
format  for  graphic  input  files.  However,  VAPS  is  compatible  with  AutoCAD  and  PostScript 
files,  and  it  provides  device  suppxrrt  for  non-standard  hardware  in  the  runtime  environment 
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Vendor  Support 

Installing  VAPS  is  a  straightfOTwaid  procedure  that  does  not  require  additicmal 
assistance  from  die  vendor.  VAPS  is  available  fn’  a  trial  evaluation  period.  It  also  offers 
excellent  training  courses.  The  classes  are  conducted  by  both  a  professitmal  educator  and  a 
software  engineer.  Each  day  of  the  week-long  course  is  divided  between  lecture  and  hands-on 
exercises.  It  costs  $2^00  per  person  plus  traveling  expenses.  The  courses  are  limited  to  a 
maximum  of  6  students  totaling  $10,500.  Virtual  Prototypes,  Inc.'s  telephone  assistance  is 
helpful;  however,  all  software  bug  fixes  are  saved  for  each  new  release.  They  will  not  send 
you  a  tape  immediately  with  the  as  some  vendors  do. 

Software/Hardware 

As  it  does  not  run  under  a  standard  windowing  system,  VAPS  cannot  be  considered  to 
be  compatible  with  industiy  standards.  Version  2.05  runs  on  Ae  Silicon  Graphics,  IBM  and 
Sun  wc^tations.  It  is  currently  being  modified  to  run  on  more  hardware  platforms.  It  also 
accepts  data  across  an  Ethernet  network,  TCP/IP,  and  15553B  from  an  external  simulation  or 
database,  and  accepts  input  from  multiple  display  devices,  including  touchscreen,  mouse,  track 
ball,  and  keyboard. 

3.2.7  Summary 

Because  its  emphasis  is  on  objects  such  as  lights,  buttons,  knobs,  and  dials,  VAPS  is 
well-suited  to  modeling  hardware  devices.  The  new  objects  in  version  2.05  make  it  possible  to 
model  complex  display  consoles.  Another  major  stren^  is  that  VAPS  enables  a  developer  to 
quickly  and  easily  build  and  modify  a  user  int^ace.  It  is  a  hi^-end,  powerful  rapid 
^totyping  tod.  It  can  significantly  reduce  the  development  time  of  a  prototype,  in  contrast  to 
the  time  required  by  many  txher  commercial  rapid  prototyping  tools.  However,  code 
optimization  should  be  kept  in  mind  to  minimize  overhead  and  maximize  response  time. 
Another  drawback  is  that  VAPS  is  expensive.  Version  1.04  costs  from  $50,000  to  $100,000. 
The  price  of  2.05  was  reduced  to  $15,000  to  $41,000.  Finally,  because  of  its  overhead 
requirements,  it  is  only  feasible  to  run  VAPS  on  high  performance  workstations,  such  as  the 
Silicon  GrapMcs. 

3.3  LUIS/SMS 

3.3.1  Overview 

LUIS/SMS  consists  of  an  integrated  environment  of  two  separate  but  related  systems. 
The  first  is  tire  Lockheed  User  Interface  System  (LUIS),  which  provides  a  deeply  nested 
menuing  system  to  support  development  of  a  user  interface.  The  second  is  the  Softcopy  Map 
System  (SMS),  which  supports  devel(g)ment  of  geographical  mapping  systems.  Although 
LUIS  and  SMS  can  both  run  as  stand-alone  systems  or  as  an  inte^t^  package.  LUIS 
provides  the  interface  thrmigh  which  the  user  can  interact  with  the  mapping  system.  Moreover, 
without  the  advantages  of  SMS'  special  mapping  c^abilities,  there  are  many  user  interface 
develq>ment  systems  that  are  easier  to  use  than  LUIS.  As  a  package,  however,  LUIS/SMS 
provides  a  unique  set  of  capabilities. 
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The  version  described  in  this  paper  axe  LUIS  6.33b  and  SMS  6.63.  The  newest 
version,  LUIS  n,  is  cuiiently  being  distributed.  It  runs  on  the  Digital  Equipment  Coiporation 
(DEQ,  Hewlett  Packard  (Iff  )/Apollo,  Silicon  Graphics,  Inc.  (SGI),  and  Sun  4  workstations. 
The  entire  system  costs  approximately  $50,000. 

LUIS/SMS  was  designed  by  Lockheed  to  support  military  applications  that  involve 
geogitqrhical  mtqrs.  It  can  support  many  different  levels  of  map  detail,  and  it  provides 
mechar^ms  for  ensuring  optimal  performance.  The  LUIS  user  interface  tool  will  be  discussed 
first,  followed  by  a  description  of  SMS  capabilities.  Finally,  there  will  be  a  discussion  of  the 
integrated  LUIS/SMS  environment 

3.3.2  LUIS 

LUIS  is  a  user  interface  develt^ment  system  that  provides  a  menu-based  editor  as  well 
as  a  ctxnmand  langiuge.  Its  unique  features  include  easy  integration  of  the  user  interface  with 
an  external  applicatitxi  program,  and  user  input  logging,  which  can  be  useful  for  usability 
testing  of  a  user  interface.  LUIS  consists  of  three  major  comptments;  a  dialog  editor,  a 
grrq)lucs  editor,  and  a  parser.  The  dialog  editor  supports  creation  and  modification  of  user 
interface  displays  or  "panels"  using  menus  and  sin^e-letter  commands.  It  also  automatically 
generates  user  interface  lan^ge  code  of  the  graphic  user  interface  in  an  "author  file."  LUIS 
objects  consist  of  visible  objects,  including  panels,  buttons,  and  menus,  and  functional  objects 
that  supply  logical  functions,  such  as  AND,  NAND,  and  XOR  evaluators. 

Visible  Objects 

LUIS  visible  objects  are  interactive  objects  that  can  be  seen  by  the  end  user.  A 
complete  list  of  visible  objects  includes  panels,  pop-ups,  buttons  (or,  as  they  are  called  in 
LUIS,  optitxis),  rectangles,  text,  text  fields,  and  analogs.  A  panel  is  a  distinct  screen  in  the 
userint^ace.  A  pop-up  is  a  window  that  is  located  within  a  panel.  An  option  is  a  selectable 
butUMi.  A  text  field  is  an  area  in  which  the  user  may  enter  alphanumeric  data.  Finally,  an 
analog  is  a  measurement  device,  such  as  rulers,  meters,  and  gages,  to  which  the  user  can 
assign  numeric  values. 

The  available  attributes  differ  for  each  type  of  object  Panel  attributes  include  text  color, 
background  color,  progress  color,  text  font  cursor  aid,  cursor  pattern,  mouse  input  keyboard 
input  and  time  and  date.  The  attributes  applied  to  the  panel  are  also  applied  as  default  attributes 
to  its  "children,”  objects  that  reside  on  the  panel.  For  example,  if  no  text  color  has  been 
specified  for  a  text  input  field,  the  text  will  have  the  color  defined  for  the  panel.  "Progress 
color"  applies  to  aiuilog  indicators,  such  as  th^  mercury  in  a  thermometer.  "Cursor  aid"  is  a 
category  of  attributes  that  apply  to  objects  as  the  cursor  interacts  with  them.  For  example,  if  the 
color  or  pattern  of  a  button  should  change  when  the  mouse  cursor  is  over  it,  the  cursor  aid 
would  define  those  attributes.  The  cursor  can  be  a  small  rectangle,  a  crosshair,  or  a  pointing 
arrow.  The  time  and  date  are  also  supplied  directly  to  the  panel  as  attributes. 

The  pop-up  can  contain  a  group  of  (Ejects,  or  become  a  pop-up  window  displaying  a 
scrollable  text  file.  The  unique  pop-up  attributes  are  shadowing,  d^amic  position,  cursor 
home,  pull  down,  scroll  bar,  and  dynamically  created  optitms.  Cation  attributes  include 
selecting  a  box  size  and  specifying  the  implications  or  actions  to  be  executed  upon  selection  or 
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deseiecti(m  of  the  The  shape,  scale  factOT,  and  indicator  minimum  and  maximum 

values  can  be  speciHed  for  analogs.  "Shadowing"  refers  to  a  shadow  that  appears  around  a 
pop-up  window,  adding  a  "3D"  look.  "Dynamic  position"  allows  the  pop-up's  position  to  be 
dyn^ically  determined  during  runtime,  based  on  the  position  of  the  cursor.  The  "cursor  home 
posititm"  is  where  the  cursor  appear  when  a  panel  first  appears  on  the  screen.  Other 
notable  object  attributes  include  specifying  the  size  of  a  rcctan^e,  defining  a  text  string  as 
blinking  text,  and  declaring  a  text  field  to  be  formatted  or  justifiol,  with  numeric  or  alphabetic 
input  values. 

Functional  Objects 

Functional  objects  are  actually  operations  to  be  performed.  Functional  objects  can 
specify  logical  relationships  between  a  series  of  options  such  as  AND,  NAND,  and  XOR,  or 
they  can  be  states,  implicatitxis,  or  actions.  A  "state"  specifies  a  logied  expression  to  be  tested 
during  interface  execution.  For  example,  if  an  expression  is  evaluated  to  be  "TRUE",  then 
certain  actions  called  "implications"  wdl  be  executed.  An  "implication"  sp^tifies  a  list  of 
interface  operations  that  are  carried  out  in  sequence  after  a  designated  event,  such  as  evaluation 
of  a  state  to  be  "TRUE"  or  selection  of  an  option.  Examples  of  implications  are  enable, 
disable,  select,  deselect,  save,  copy,  move,  clear  and  object,  fire  an  action,  set  an  analog,  go  to 
a  panel,  refinesh  the  screen,  and  exit  the  interface.  An  action  calls  a  programming  routine  to  be 
executed. 

The  visible  and  functional  objects  are  created  and  integrated  into  the  user  interface  in  the 
dialog  editor.  The  LUIS  dialog  editor  is  analogous  to  the  graphics  editor  in  many  other  rapid 
prototyping  systems.  It  is  that  pan  of  the  system  in  which  most  of  the  user  interface 
devel^ment  is  accomplished.  LUIS  also  has  a  graphics  editor,  but  it  is  used  for  special  cases. 
For  example,  the  graphics  editor  supports  creation  and  tailoring  of  unique  analogs  and  custom- 
made  q)tion  icons.  Objects  built  in  Ae  graphics  editor  must  be  brought  into  the  dialog  editor  to 
be  incorporated  into  a  prototype. 

The  dialog  editor  produces  a  textual  description  of  a  graphic  user  interface  in  an  "author 
file".  The  LUIS  "authOT  ^e"  is  an  ASCII  file  containing  a  collection  of  object  definition 
statements.  Having  this  intermediate  author  file  provides  a  user  interface  Iwguage  alternative  to 
the  menu-based  system  of  LUIS  for  user  interface  development  The  author  file  parser 
interprets  the  high-level  statements  in  the  author  file,  and  creates  the  display  list  (hiring 
development  and  at  rxmtime.  Parsing  is  required  the  first  time  an  author  file  is  created  and 
when  the  interface  is  mtxlified  Parse  time  is  negligible  for  small  interfaces,  but  may  be 
considerable  for  interfaces  consisting  of  two  or  mcne  panels. 

3.3.3  SMS 

SMS  is  a  portable  software  t(X)l  that  suppevts  rapid  development  and  integration  of 
maps  into  C3I  applications  and  can  accept  map  data  from  many  sources,  including  the  World 
DataBank  and  USGS.  It  provides  a  library  of  900  routines,  all  of  which  handle  various  aspects 
of  map  display  generation,  including  map  database  access,  terrain  shading,  graphic  utilities, 
and  system  management.  Terrain  shading  refers  to  special  effects,  such  as  range  shading  and 
peak  definition. 
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The  maps  are  displayed  as  a  series  of  overiays  that  can  be  toggled  on  and  off.  The 
overiays  can  contain  separate  po^ons  of  the  map,  such  as  country  boundaries,  altitude 
sha^g,  peak  definition,  majOT  rivm,  major  roads,  major  cities,  and  city  labels.  The  graphic 
utilities  include  the  low-level  graphic  drawing  necessary  to  support  the  more  complex  maps  as 
well  as  transformations  such  as  rotation  and  scaling.  System  management  routines  handle 
features  such  as  map  legends,  paiming,  and  zooming. 

SMS  ctmsists  of  a  worldmap,  display  configuration,  device  description,  units,  symbol 
format,  and  symbol  databases.  Its  woridmap  database,  which  defines  what  is  available  to  be 
di^layed  by  SMS,  contains  all  the  available  m^  data.  The  display  configuration  database 
defines  how  the  data  is  to  be  displayed,  specifying  special  features  and  attributes.  The  device 
description  database  contains  definitions  of  colors  available  for  use  in  display  configuratitm;  it 
defines  the  RGB  (red,  green,  and  blue)  components  of  all  the  available  colors.  The  symbol 
format  database  ctmtains  definitions  of  the  types  of  symbols  or  icons  to  be  displayed  cm  the 
map.  These  databases  reduce  the  complexity  of  creating  a  map  applicatitm  wiA  SMS;  the 
developer  has  tmly  to  modify  them  to  tailor  them  for  a  particui^  application. 

LUIS/SMS  functions  as  an  integrated  envinmment.  LUIS  handles  the  user  interface 
development,  accepting  input  requests  tom  tlw  user  during  runtime  and  calling  Ae  appropriate 
SMS  routine.  SMS  handles  the  mapping  cap^ilities  and  is  treated  as  any  apphcation  system 
by  LUIS.  Other  ^licaticm  programs  can  be  easily  bouTKl  with  a  LUIS  int^ace.  LinSis 
bound  to  applicaticm  through  a  special  "process  selection”  file,  a  programming  routine  that  must 
be  created  by  the  developer.  It  accepts  a  process  name  as  user  input  and  then  calls  the 
q>ptopriate  process  routine. 

3.3.4  Prototype  Development  Steps 

The  steps  involved  in  building  an  ty)plication  with  LUIS/SMS,  not  necessarily  in  this 
order,  are  as  follows:  design  the  panels,  build  die  user  interface  within  die  dialog  editor,  create 
special  graphic  objects  in  Ae  graphics  e^tor,  parse  author  file,  modify  the  appropriate 
databases,  and  generate  the  special  process  selection  file  to  bind  LUIS  and  the  ^plication. 

3.3.5  Evaluation 

Capabilities 

LUIS/SMS  is  one  of  the  few  rapid  prototyping  tools  that  combines  a  user  interface 
develt^ment  system  with  a  geographic^  mapping  system.  This  mates  it  particularly  useful  for 
military  applications,  as  they  often  require  the  use  of  map  displays.  LUIS/SMS  allows  maps 
to  be  easily  manipulated,  zoomed,  panned  and  reset  It  dso  provides  toggle  overlays,  which, 
for  example,  allow  the  major  rivers  to  be  removed  from  a  map  without  having  to  re^w  the 
entire  display.  Toggle  overlays  are  important  to  performance  in  drawing  complex  maps  with 
terrain  shading  and  elevation  shading,  in  addition  to  roads,  rivers  and  cities. 

Alphanumeric  and  text  labels  are  considered  part  of  the  LUIS  display  objects,  so 
the  entire  object  must  be  recreated  to  change  the  label.  Special  highlighting  effects  such  as 
reverse  video  and  flashing  are  easy  to  implement.  The  system  can  also  do  user  input  logging. 
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The  logs  are  time-stamped  and  saved  in  a  fmmatted  ASCII  file;  but  the  logging  applies  only  to 
LUIS  objects,  not  to  SMS  objects. 

Usability 

The  LUIS  inteiface  description  file,  or  autliOT  file,  includes  implication  objects  that 
specify  the  actions  to  be  taken  according  to  the  end  user's  input  For  example,  when  the  end 
user  setects  a  button,  the  implication  may  be  that  a  pop-up  ^pears  on  the  screen.  Upon  de¬ 
selection,  die  implication  might  be  to  cause  the  pq>-up  to  dist^pear.  The  developer  can  define 
the  implications  throu^  the  LUIS  menuing  system  or  by  entering  them  directly  into  the  author 
file.  In  this  way,  LUIS/SMS  supports  boA  novice  and  expert  users.  However,  although  the 
menus  are  intended  to  support  the  novice  user,  tlwy  are  deeply  nested  and  can  be  confusing  to 
use.  They  are  sometimes  five  or  six  levels  deep,  and  sane  have  twenty  or  more  elements. 

Objects  can  be  placed  on  the  screen  according  to  a  grid.  The  placement  can  be  fine- 
tuned  within  the  author  file.  The  author  file  is  automatically  generated  by  the  dialog  editor,  and 
can  be  modified  by  the  developer. 

Custom-made  objects  must  be  created  in  tte  gr^hics  editor.  Because  custon-made 
objects  are  not  a  major  emphasis  within  LUIS/SMS,  its  graphics  editor  is  rather  limited  and 
diffiettit  to  use.  Hie  toggle  overlays,  an  important  feature  of  SMS,  avoid  serious  degradation 
of  performance  for  applications  in  which  complex  map  data  is  being  manipulated. 

Nevertheless,  it  is  best  to  run  SMS  on  a  high-end  wo^tation,  such  as  the 
Sun  4. 


LUIS/SMS  provides  a  flexible  environment  for  development  It  does,  however, 
require  training,  and  has  a  steep  learning  curve.  The  documentation  is  usable,  although  it 
would  benefit  £i^  review  by  a  human  factors  person  to  minimize  some  of  the  technical 
terminology. 

Confirmation  checks  are  only  used  when  exiting  the  LUIS/SMS  system.  However, 
LUIS/SMS  has  file  recovery  methods.  As  each  new  author  file  is  created,  it  is  assigned  a 
".mod”  extension.  Thus,  the  next  to  last  version  of  the  author  file  would  have  the  extension 
".mod.mod"  and  so  fortii.  In  addition,  a  directory  called  "rcb,"  which  contains  binary  files 
describing  the  user  interface,  is  automatically  generated . 

Vendor  Support 

LUIS/SMS  is  complex  to  install,  and  die  vendor  does  not  regularly  send  a 
representative  to  assist  Tlw  enviromnent  and  the  paths  must  be  carefully  set  up.  The  best  bet 
is  to  have  it  installed  by  a  professional  system  administrator.  However,  the  newest  version, 
sooi  to  he  release,  LUIS  n  is  easier  to  install  and  setup. 

LUIS/SMS  can  be  obtained  for  a  trial  evaluation  period.  The  training  courses  offered 
by  Lockheed  are  sometimes  poorly  structured  and  are  not  always  taught  by  professional 
educators,  but  Locldieed  is  currently  trying  to  improve  the  training  system.  The  courses  run 
for  a  week  at  $4600  plus  traveling  expenses.  They  are  limited  to  a  maximum  of  6  students. 
The  steep  learning  curve  associated  with  LUIS/SMS  complicates  the  training  process. 
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Lockheed  is  not  always  accurate  and  timely  with  its  telephcme  assistance.  However,  it  is 
willing  to  bugs  immediately  and  send  the  user  a  temporary  tape  with  the  fixed  version  until 

the  next  version  release. 

Software/Hardware 

LUIS/SMS  is  not  compatible  with  a  standard  window  system,  but  it  does  use  Extended 
GKS  as  its  lower  level  gn^hics  package.  It  is  pcntable  to  other  platforms,  but  not  as  portable 
as  it  might  be  if  it  were  ba^  on  a  windowing  system  such  as  X  Windows.  It  can  accept  most 
World  Database  data  files  as  input,  but  again,  it  restricts  the  format  that  it  can  accept 

3.3.6  Summary 

The  strengtiis  of  the  integrated  LUIS/SMS  package  are  numerous.  First  LUIS  enables 
the  develqrer  to  create  the  user  interface  without  programming.  The  developer  can  create  both 
the  "look"  and  the  "feel"  of  the  interface  indepen^nt  of  any  coding.  Through  a  complex 
menuing  system,  die  developer  can  create,  position,  and  modify  panels  and  objects  aixi  specify 
the  functioiudity  behind  them.  The  menus  ^ow  the  developer  to  specify  an  implicatitm  to  be 
executed  when  an  t^tion  is  selected  or  deselected.  LUIS  requires  coding  much  later  in  the 
development  process  than  do  many  other  rapid  prototyping  tools.  Coding  is  necessary  to  bind 
the  application  programs  (such  as  SMS)  to  the  LUIS  interface. 

Another  major  strength  of  LUIS/SMS  is  that  it  combines  the  capabilities  of  user 
interface  design  wiA  map  display  generatitm.  This  is  a  unique  combination,  and  one  that  is 
very  useful  for  C3I  applications.  LUIS/SMS  provides  good  text  handling  capabilities.  It 
malres  creating  a  text  input  re^cm  or  a  scroll  bar  in  a  text  pq)*up  easy.  Its  input  logging  feature 
is  very  useful  for  performing  usability  testing  on  the  interfaces  developed  with  LUIS/SMS. 

And  it  runs  on  a  wide  range  of  hardware  platforms. 

There  are  tradeoffs,  of  course.  For  example,  the  same  complexity  of  the  menuing 
system  that  allows  the  developer  to  create  the  "look  and  feel"  of  the  interface  independent  of 
ptogranuning  also  can  cause  the  tool's  interface  to  seem  complicated  and  cumbersome.  Also, 
altiiough  programming  is  not  required  quite  as  early  in  the  development  process  as  with  many 
other  tools,  the  integrated  LUIS^MS  does,  in  fact,  require  a  substantial  amount  of  coding  to 
create  a  mapping  application.  All  the  related  databases  must  be  modified,  and  a  process 
selection  file  must  be  created.  The  coding  within  these  Eles  has  rather  strict  syntax 
requirements.  It  includes  over  tiuee-huridted  high-level  geogrq)hical  mapping,  display  object 
manipulation  and  inter-process  communication  (tetween  LUIS  and  external  applications) 
programming  routines.  There  is  a  steep  learning  curve  associated  with  the  tool. 

3.4  SL-GMS 

3.4.1  Overview 

The  Graphical  Modeling  System  fnxn  the  SL  Corporation  in  Cone  Madera,  CA  is  a 
genoal  purpose  rapid  prototyping  tool.  It  supp^  easy  generation  of  grqrhic  objects  and 
assigiunent  of  dynamics  to  tiiem.  This  evaluation  was  based  on  version  3.0fl,  however,  the 
current  version  4.0  will  also  be  discussed.  SL-GMS  runs  on  Sun,  Megatek,  Silicon  Graphics, 
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VAXstation,  and  HP  9000/30(yApollo  workstations.  Its  cost  is  $12,000  per  license  for 
development  license  and  $2,500  for  just  a  runtime  license. 

SL-GMS  was  oiiginaUy  designed  to  support  the  development  of  process  control 
implications  for  manufacturing  envirtmments.  However,  it  has  evolved  into  a  general  purpose 
rapid  prototyping  tool. 

SMjMS  consists  of  two  main  components.  First,  it  provides  an  easy-to-use 
interactive  gnmhics  editor  called  "SL-Draw.”  SL-Draw  supports  development  of  dynamic 
graphic  displays  and  objects.  A  display  along  with  the  objects  that  reside  on  it  is  cidled  a 
"modeL"  The  "look"  df  a  prototype  can  be  created  with  SL-Draw,  indq)endent  of  coding. 

The  user  interface  can  be  stored  in  both  an  ASQI  file  and  a  binary  code  ^e.  The  editable  file 
has  ".g”  as  an  extensitm;  the  non-editable  file  has  ".ml”  as  an  extensitxi.  For  example,  if  a 
model  were  saved  as  "space_data”,  SL-Draw  would  automatically  generate  "space_data.g"  and 
"space_data.m". 

Second,  SL-GMS  provides  a  functitxi  library  called  "SL-GMF"  of  over  1000 
routines.  These  routines  can  be  embedded  within  a  C,  FORTRAN,  Ada,  or  Pascal  control 
program.  ("G)ntrol  program"  is  the  term  that  we  will  use  to  refer  u>  the  program  that 
"controls"  the  hincdonality  of  a  prototype,  such  as  die  sequencing  of  di^lays  and  the  handling 
ck  input  events.)  Unlike  the  ".g"  file,  the  control  program  must  be  develop^  by  the  prototype 
developfT. 

3.4.2  SL-Draw  Graphics  Editor 

SL-Draw  supports  a  wide  range  of  graphic  primitives,  including  rectangles,  curves, 
triangles,  circles,  ovals,  arcs,  markers,  text  and  splines.  The  attributes  that  can  be  applied  to 
these  objects  include  line  style,  line  width,  line  color,  text  color,  object  color,  object  pattern, 
font  size,  font  style,  and  marker  style. 

SL-Draw  also  supports  a  large  number  of  operations  that  can  be  performed  on  the 
grq)hic  objects.  An  object  can  be  filled  with  a  pattern,  unfilled,  rotated,  moved,  mirrored, 
sealed,  and  deleted.  The  snap,  add,  and  delete  points  can  be  used  to  modify  an  object  created 
with  splines.  A  point  connecting  the  spline  drawings  can  be  added,  delete^  or  snapped  to  a 
new  position.  With  the  splines,  die  last  point  can  also  be  cancelled  by  the  "backup"  oi^ration. 
Any  type  of  operation  that  was  perform^  last  can  be  cancelled  widi  the  "undo"  operatitm. 
Liinit^  functionality  for  the  di^lay  objects  can  be  defined  within  SL-Draw,  but  a  prototype 
requires  a  control  program  to  make  it  fully  functional. 

3.4.3  GISMOs 

In  version  3.0fl,  the  only  high-level  grtqihic  object  provided  was  the  selectable  button. 
VersicMi  4.0,  provides  an  extension  of  the  original  graphics  editor  objects.  It  supplies  a  set  of 
ready-to-use  Graphical  Interactive  Screen  Management  Objects  (GISMOs).  The  most 
significant  change  in  Version  4.0  is  that  it  is  compatible  with  the  X  Window  System.  X 
Windows,  an  emerging  industry  standard,  allows  an  application  to  be  distiibu^  across  a 
network,  sharing  displays  among  a  heterogeneous  set  of  workstations.  The  X  Toolkit  is 
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software  that  supports  implementatitm  of  the  user  interface  "look  and  feel."  Also,  a  Motif 
’look  and  feel”  can  be  ad^  to  any  sq)plicati(m. 

The  SL<}MS  GISMOs  are  intended  to  supplement  the  X  Toolkit  They  can  be  used  to 
control  input  events,  such  as  mouse  or  keyboard  input  Fcr  example,  "DATSCREEN"  is  a 
GISMO  that  displays  a  new  screen  and  activates  a  fite  that  contains  tte  screen's  dynamics. 
Similarly,  the  "SCREEN"  GISMO  displays  a  new  screen.  "NEW  POPUP"  displays  a  pop>up 
menu  or  a  dialog  box.  "RETURN"  causes  die  intt^ace  to  return  to  tiie  previous  screen. 
"QUIT"  exits  the  application  program.  "CALL"  invokes  the  specified  applkatitxi  function. 
"FLASH"  calls  an  q>plication  function  wiA  "flash"  highli^ting.  "STAYON"  calls  an 
{plication  ftmction  witii  highlighting  in  which  an  object  stays  in  the  "oa"  state,  however  that  is 
defined  "RADIO"  calls  an  arotication  function  and  allows  only  one  GISMO  to  be  highlighted 
at  a  time.  "TOGGLE”  calls  a  ftmction  with  a  highlighting  capability  tiiat  turns  a  GISMO  cm  or 
off,  dq)ending  on  its  current  state.  There  are  also  text-handlmg  and  dynamic-handling 
GISMOs,  such  as  "SLIDER"  and  "FILL  PERCENT."  The  Ubrary  of  GISMOS  can  be 
expanded  to  contain  custom-made  objects. 

3.4.4  SL-GMF  Function  Library 

SL-GMF,  the  function  library,  contains  over  1000  programming  functions.  After  the 
screens  and  objects  are  defined  the  next  step  is  to  create  a  control  program  with  embedded  SL- 
GMF  routines.  The  SL-GMF  routines  provide  high-level  functions,  such  as  initializing  SL- 
GMS,  defiitmg  the  initial  model,  redrawing  die  screen,  changing  die  color  of  an  object,  turning 
off  the  visibility  of  a  pt^up  window,  and  navigating  to  another  model.  Functitxial  "hooks"  to 
de  coitrol  program  can  be  defined  within  SL-DRAW.  For  example,  if  a  display  has  two 
buttms,  one  button  can  call  the  "pq>-up-window"  routine  with  parameter  (1)  and  the  other  can 
call  it  with  parameter  (2).  The  code  then  checks  the  parameter  passed  by  SL-Draw  and  pops  up 
the  apprcqiriate  window. 

3.4.5  Prototype  Development  Steps 

To  create  a  fully  functional  prototype  using  SL-GMS,  the  developer  must  accomplish 
two  main  tasks:  create  the  delays  in  SL-Draw,  and  generate  the  control  program.  Creating 
the  displays  includes  building  the  objects  from  the  primitives,  placing  them  within  a  ^d  on  the 
displays,  and  defining  the  "hooks"  to  the  control  program.  Because  all  functionality  is  defined 
in  the  control  program,  coding  must  begin  early  in  the  develt^ment  process.  The  process  of 
developing  the  control  program  can  often  be  simplified  by  using  at  l^t  the  be^n^gs  of  a 
sample  control  program.  Many  of  the  SL-GMS  calls  in  the  main  program  are  similar  for  every 
i^plicatioiL  GMSRUN  is  a  new  program  offered  by  SL  Corp.  that  allows  a  prototype  to  run 
without  a  control  program. 

3.4.6  Evaluation 

Capabilities 

While  SL-GMS  allows  the  developer  to  draw  a  map  using  the  ftee-draw  primitive  in 
SL-Draw,  it  does  not  directly  support  development  of  vector-drawn  maps.  Maps  can  be 
imported  from  outside  sources,  ^though  that  is  not  a  simple  process.  And  while  SL-GMS 
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objects  can  be  zoomed,  panned  and  reset  in  SL-DI^W,  they  cannot  be  manipulated  similarly 
by  die  end  user  unless  low-level  zoom  and  pan  code  is  written  in  the  control  program. 

SL-GMS  provides  text-handling  features  such  as  text  input  fields;  however,  it  is 
comparatively  difficult  to  make  these  fields  formatted  ami  editable.  Text  can  be  placed 
anywhere  on  a  SL-GMS  screen.  Text  can  also  serve  as  labels  on  buttons,  and  the  labels  can  be 
modified  without  recreating  the  entire  object  Version  4.0  of  SL-GMS  is  compatible  with  the  X 
Window  System;  however,  it  is  difficult  to  use  the  gr^hics  editor  in  any  size  but  full-screen, 
as  the  palette  and  the  menu  bars  become  too  small  to  work  with. 

Usability 

Within  the  SL-Draw  graphics  editor,  graphic  objects  are  created  and  their  attributes 
defined  through  a  set  of  gn^hic  icons.  The  developer  can  directly  manipulate  these  objects 
with  a  pointing  device  such  as  the  mouse.  Most  of  the  icons  have  picture  labels  that  represent 
primitives  such  as  circle,  rectangle,  arc  and  butmn.  Operations  such  as  rotate,  scale,  and 
duplicate  also  have  picture  icons.  However,  files  cannot  be  directly  manipulated;  that  must  be 
done  throu^  operating  system  commands. 

SL-Draw  also  provides  a  set  of  single-layer  menus  along  a  menu  bar.  The  menus 
provide  functionality  such  as  selecting  and  grouping  objects,  turning  the  object  placement  grid 
on  and  off,  and  saving  the  ".m”  or  ".g"  description  of  a  model.  The  objects  are  located  on  the 
screen  by  snapping  them  to  a  grid  that  can  be  set  at  various  block  sizes.  The  object  location  can 
also  be  "tweaked"  by  changing  the  screen  position  numbers  in  the  control  prog^.  However, 
this  often  requires  many  calculations,  and  is  is  more  difficult  after  an  object  is  size-scaled. 

There  is  also  an  "XForm"  functicMi  that  can  assist  in  moving  objects.  Objects  can  easily  be 
placed  in  fiont  or  back  of  other  objects.  There  are  sixty-four  available  drawing  colors  in  the 
graphics  editor  are  limited  to  sixty-four. 

SL-GMS  supports  both  the  novice  and  the  expert  developer.  The  novice  can  use  the 
graphic  icon  palette  in  SL-Draw,  while  the  expert  can  create  objects  and  define  their  attributes  in 
command  language  in  the  control  program.  Both,  however,  must  be  able  to  develop  the  control 
program. 

SL-GMS  provides  many  confirmation  checks  within  SL-Draw.  It  supplies  obstacles  to 
erasing  a  file,  moving  frcxn  one  model  to  another  without  saving,  and  exiting  the  system 
unintentionally.  It  a^  creates  backup  files  when  the  developer  saves  a  new  version  of  a  file. 
The  system  {voduces  both  an  editable  interface  description  ffie  and  a  binary  one.  This  ensures 
that  the  changes  made  to  the  editable  file  are  not  automatically  incorporated  into  the  prototype 
unless  the  developer  issues  commands  to  do  so. 

SL-GMS  provides  a  flexible  development  process.  The  functional  links  between  the 
SL-Draw  objects  and  the  control  program  routines  can  be  created  in  any  (vder.  The  system  will 
not  produce  an  error  if  a  routine  is  specified  in  SL-Draw  that  is  not  defined  in  the  control 
program  until  compilation.  There  can  be  a  steep  learning  curve  associated  with  using  the  SL- 
GMF  routines  effectively,  mostly  due  to  the  software  bugs.  The  routines  do  not  always 
perform  as  stated  m  the  documentation.  For  this  reason,  it  is  sometimes  necessary  to  perform 
programming  tricks  with  GMF  calls  to  accomplish  a  simple  task,  such  as  making  an  object 
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appeal  and  disappear.  Moreover,  the  functionality  of  the  SL-GMS  GISMOs  is  rather  basic, 
and  similar  features  are  available  through  the  Motif  Toolkit  The  documentation  will  present  a 
problem  for  both  the  novice  and  the  expen  user.  It  does  not  always  address  the  details 
necessary  to  create  an  executing  prototype.  The  documentation  for  version  4.0  has  been 
improved 

SL-GMS  does  not  require  much  oveihead  and  so  can  run  on  a  Sun  3  with  acceptable 
response  time.  However,  this  minimalization  of  overhead  forces  the  user  to  pre^gram  rather 
early  in  the  development  process,  as  do  the  limited  graphic  objects  that  are  provided 

Vendor  Support 

Installation  of  SL-GMS  is  not  difficult  SL  Corporation  will  provide  trial  evaluation 
periods  and  training  classes.  The  training  courses  cost  $100  per  hour  plus  $250  per  student  per 
day.  They  are  limited  to  a  maximum  of  3  students  for  4  days.  The  company's  telephone 
assistance  can  be  helpful,  although  the  hours  are  limited  since  all  the  technical  s^ptm  is 
located  cm  the  West  Coast  To  address  this  problem,  SL  Corp.  has  set  up  a  distribution  office 
in  Washington  D.C. 

Software/Hardware 

To  adhere  to  industry  standards.  Version  4.0  of  SL-GMS  became  compatible  with  the 
X  Window  System.  The  GISMOs  are  SL-GMS'  own  extension  to  the  X  Toolkit 

3.4.7  Summary 

SL-GMS  is  relatively  inexpensive  compared  to  some  of  the  higher-end  tools,  and  yet  it 
is  a  good  general  purpose  tool.  It  frees  the  "look"  of  the  prototype  from  all  graphics  coding. 
Screen  development  is  easy  and  flexible.  SL-GMS  requires  programming  early  in  the 
development  process.  Development  of  the  interface  requires  programming  in  a  standardized 
language  such  as  C  or  FORTRAN  and  also  learning  the  SL-GMF  (function  library)  calls. 

The  learning  curve  associated  witii  SL-GMF  can  be  steep,  though  it  is  not  as  difficult  as 
those  of  some  more  powmful  tools.  SL-GMS  also  minimizes  overhead  and  frees  the  developer 
from  worry  over  performance.  It  is  well-suited  to  interfaces  that  only  require  buttons  and  text 
input  fiel^,  and  ^  not  require  complex  geographical  maps. 

33  TAB  PLUS 

3.5.1  Overview 

TAE  Plus  is  a  portable,  X  Window-based  software  package  that  supports  the  design 
and  development  of  interactive  graphic  user  inrerface  application  systems.  It  was  develop^  by 
the  NASAAjoddard  Space  Flight  <>nter  and  is  distributed  by  COSMIC,  NASA's  software 
distribution  center  located  at  tire  University  of  Georgia.  Version  4. 1  was  evaluated  and  is 
discussed  here.  Version  S.l  was  released  in  May  1991.  TAE  Plus  is  based  on  the  X  Window 
System,  XI 1  Release  3  and  allows  the  developer  to  build  a  user  interface  under  X  Windows 
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without  requiring  an  understanding  of  the  complexities  of  X.  However,  it  allows  the  developer 
to  access  the  X  toolkit  and  X  libn^  directly  if  necessary.  TAE  Plus  runs  on  Sun  3  and  4, 
DECstation,  and  HP/ApoUo  workstations.  Version  4.1  cost  is  $500  for  the  general  public  and 
$250  for  die  govermnent  Version  5.1  costs  $750  and  $350  respectively. 

TAE  Plus  supplies  a  wide  range  of  ready-made,  high-level  display  objects  such  as  pull¬ 
down  menus,  check  toxes,  radio  buttons,  and  scroll  bars.  It  is  therefore  very  useful  for  user 
interfaces  that  require  many  different  interactimi  styles. 

TAE  Plus  consists  of  two  main  subsystems:  the  WorkBench  and  the  Window 
Programming  Tools  (WPT).  The  WorkBench,  the  primary  tool  for  user  interface  development, 
can  be  used  to  interactively  create  or  edit  the  graphic  portion  of  the  intorface,  store  the  result  in  a 
file,  and  generate  an  tqrplication  program.  The  develqrer  can  then  use  the  WPT  library  of 
programming  routines  to  add  functionality  to  the  interface.  TAE  also  provides  a  graphics  editor 
called  "Idraw,"  but  it  is  used  only  for  creating  and  customizing  special  data-driven  object  types. 
All  the  interface  development  is  done  in  the  WorkBench. 

3.5.2  WorkBench 

The  TAE  Plus  WoritBench  is  a  development  tool  that  facilitates  interactive  design  of 
graphic  user  interfaces.  TAE  Plus  interfaces  consist  of  panels  and  interactive  objects.  An 
int^ace  is  made  up  of  (me  or  more  independent  parent  panels.  The  interactive  objects,  or 
presentation  items,  resi^  on  the  panels:  buttons,  icons,  check  boxes,  radio  buttons,  statics, 
text,  pull-down,  text  lists,  page  e^ts,  text  displays,  workspaces,  and  data-driven  objects.  All 
these  presentatitm  types  are  interactively  created,  modified  and  positioned  on  a  ps'ent  panel 
using  the  TAE  Plus  WorkBench. 

3.5.3  Presentation  Types 

Some  of  the  TAE  presentation  type  names  are  not  self-explanatory.  It  is  important  to 
understand  their  functiontdity.  Qumsing  the  prc^)er  presentation  type  can  make  interface 
development  go  much  more  smcmthly.  For  example,  the  radio  buttons  are  mutually  exclusive, 
while  check  boxes  are  not  Most  of  Ae  TAE  Plus  presentati(m  items  are  interactive.  The 
exceptions  to  this  are  the  static  text  item,  which  is  primarily  a  label,  and  the  "text  display"  item, 
which  adlows  the  user  to  scroll  through  large  amounts  of  text  without  making  any  changes.  The 
text  display  item  is  a  scrollable  rectangular  area  designed  to  display  large  amounts  of  text. 

•  The  button  is  a  selectable  object,  and  upon  selection  is  automatically  highlighted  by  a 
"reverse  video"  effect 

•  An  icon  is  a  small,  selectable  graphic  object  that  serves  the  same  purpose  as  a  button, 
but  unlUre  die  button  can  be  customized  by  the  developer  in  the  bitmap  editcn*. 

•  A  check  box  is  a  selectable  box  with  a  text  label.  It  returns  either  a  "no"  or  "yes,"  or 
a  "0"  (m  "1"  to  the  application,  depending  on  the  data  type. 
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•  Radio  buttons  are  a  labeled  set  of  mutually  exclusive  choices  arranged  in  one  or  more 
columns.  Qicldng  on  any  choice  will  cause  any  previously  selected  choice  to  be 
deselected. 

•  The  static  item  is  non-selectable  text,  primarily  used  for  labeling  and  informational 
purposes.  This  text  may  be  changed  by  the  application  program  at  runtime. 

•  A  text  item  is  a  text  input  field. 

•  The  pull-down  is  a  pull-down  menu. 

•  A  text  list  is  a  scrolling  list  of  mutually  exclusive  text  choices. 

•  The  page  edit  item  is  a  simple  multi-line  text  editor  that  allows  the  end  user  to  enter 
multiple  values  for  an  item.  The  page  edit  would  be  used  when  a  text  input  field 
provides  too  small  an  editable  field. 

•  A  workspace  is  a  subwindow  within  a  TAB  Plus  panel  that  can  display  and  maintain 
XI 1  graphics.  It  is  referenced  by  both  a  name  in  the  WotkBench  and  an  XI 1 
windi^  ID.  The  workspace  behaves  as  an  independent  X  window  within  a  TAB 
Plus  panel,  and  will  provide  the  prototype  with  various  types  of  X  Window  events, 
such  as  '*Bxposure”,  "BnterNotify”.  and  "ButtonPress”.  The  workspace  can  be 
very  useful,  as  TAB  Hus  does  not  directly  support  any  complex,  specialized 
drawing,  such  as  is  needed  to  prepare  geographical  maps. 

The  objects  in  4.1  are  based  on  NffTs  Athena  widgets;  and  the  objects  in  S.l  are  based  on 
MOTIF,  a  window  manager  developed  by  the  Open  Software  Foimdation 

3.5.4  Data-Driven  Objects 

A  data-driven  object  is  a  TAB  Plus  objea  that  displays  the  value  of  tqrplicadon  data  in 
realtime.  There  are  sev^  types  of  data-driven  objects:  movers,  rotators,  stretchers, 
discretes,  stripciurts,  and  dynamic  text  They  can  be  created  by  the  interface  developer  using 
the  TAB  girq>hics  editor  Idraw,  or  they  may  be  read  in  from  an  existing  file  stored  in  Idraw 
format  A  data-driven  object  consists  of  a  static  background  and  a  (fynamic  foreground  object 
The  foreground  object  chmges  relative  to  the  value  of  application  data.  For  example: 

o  The  dynamic  foreground  of  a  mover  could  be  an  arrow  that  moves  horizontally  or 
vertic^y  akmg  a  static  background  that  resembles  a  ruler.  Its  movement  reflects  a 
value  received  from  the  ipplication  program. 

•  The  dynamic  portion  of  the  rotator  rotates  around  a  pivot  point 

•  The  stretcher  can  expand  or  contract  hmizontally  or  vertically,  similar  to  a 
thermometer. 
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•  Discretes  consist  of  several  picture  objects,  each  associated  with  a  single  value.  Only 
one  picture  is  displayed  at  a  time.  The  dismte  can  be  draught  of  as  a  series  of 
drawings  which,  when  displayed  sequendally,  can  give  the  effect  of  animation. 

•  A  stiipchart  displays  a  dynamic  implication  value  as  a  fluctuating  line. 

•  A  dynamic  text  item  consists  of  a  text  string  that  changes  with  the  values  received 
from  an  implic^fton.  For  example,  dynamic  text  could  be  used  tt>  prototype  an  alert 
message  changing  from  "low"  to  "medium"  to  "high." 

Only  the  ictxi  and  data-driven  objects  can  be  custtxnized  by  the  developer  within  the  TAB 
WorkBench. 

User  interfaces  developed  in  the  W(vkBench  are  saved  in  a  file  called  a  "resource"  file. 
The  TAE  resource  file  is  a  binary  file.  In  addition  to  designing  the  "look"  of  the  user  interface 
within  the  WorkBench,  TAE  allows  for  a  small  pmtion  of  the  "feel"  -  the  connections  between 
panels  ~  to  be  defined.  For  example,  a  button  may  be  linked  with  the  appearance  and/or 
disappearance  of  display  panels.  However,  to  define  the  functionality  of  the  interface  beyond 
simple  panel  ctmnections  requires  programming. 

3.5.5  Code  Generation 

To  support  software  development,  the  WoikBench  also  provides  an  automatic  code 
generation  capabili^.  The  generate  code  is  based  upon  the  user  interface  "look  and  feel"  as 
specified  in  the  resource  file.  TAE  Plus  can  generate  code  in  C,  Ada,  cr  TAE  Command 
Language  (TCL).  TCL  is  an  interpreted  command  language.  Although  it  provides  slower 
performance,  it  allows  the  prototype  developer  to  "rehearse"  function^ity  prior  to  the  program 
being  interpreted. 

The  code  generated  by  the  TAE  Plus  WcxkBench  is  highly  structured  and  modular.  It 
also  contains  comments  and  print  statements  for  debugging  purposes.  The  generated  code 
contains  structures  called  "event  handlers"  that  handle  the  fonctionality  of  the  interface.  Event 
handlers  are  automatically  created  for  the  connections  made  in  the  WorkBench.  Most  of  the 
modification  required  by  the  developer  to  tailor  the  code  involves  inserting  WFT  statements 
within  the  event  handlers.  The  code  generator  also  supports  initialization  of  the  panels,  and 
allocates  memory  for  a  new  set  of  interactive  objects  to  located  on  the  panel,  reading  the 

resource  (".res")  file  to  obtain  the  new  set  of  ob^ts,  and  then  creating  the  user  panel  and  its 
presentation  items. 

3.5.6  WPT  Programming  Library  and  X  Windows 

The  WPT  routines  are  callable  routines  used  to  display  and  control  an  application's  user 
interface.  They  define  and  control  TAE  Plus  panels  and  interacticm  objects.  For  example, 

WPT  routines  allow  the  attributes  of  panels  and  presentation  items  to  be  created,  modified, 
displayed,  and  deleted  during  runtime.  They  also  handle  input  firom  the  end  user.  The  X 
Library  and  Toolkit  provides  the  building  blocks  used  by  W^  to  define  the  panels  and 
presentation  items.  WPT  allows  the  developer  to  create  an  X-based  interface  without  having  to 
understand  the  complexities  of  X. 
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However,  the  developer  is  free  to  access  the  X  Toolkit  and  XLib  directly.  The  X 
Toolkit,  which  sits  on  top  of  Xlib,  is  a  library  of  routines  constructed  with  XLib  functions. 
XLib  is  a  library  of  prog^ming  routines  that  ctmtains  more  than  200  graphic  and  windowing 
functions.  The  TAE  Plus  presentation  types  represent  a  subset  of  the  functionalities  offered  by 
the  X  Toolkit  widgets. 

3.5.7  Prototype  Development  Steps 

To  create  an  executing  prototype  using  TAE  Plus,  the  devel(q)er  must  take  the  following 
steps  in  the  order  listed.  Fust,  the  panels  and  presentations  items  can  be  created  in  the 
WorkBench.  Care  must  be  taken  to  create  the  presentation  items  in  the  order  in  which  they  will 
^pear,  going  from  back  to  front  Next  the  developer  can  create  or  modify  any  custtxn-made 
icons  or  data-driven  objects.  The  sequencing  of  the  panels  can  be  specified  in  the  WoikBench 
by  selecting  "connections"  mode.  The  connections  can  also  be  "rehearsed"  in  the  WorkBench. 
Fmally,  when  the  developer  is  confident  that  the  interface  is  complete,  Ae  code  can  be 
generated.  This  is  done  by  choosing  the  "generate"  q)tion.  The  code  should  then  be  modified 
by  inserting  WPT  calls  into  the  event  handlers  and  ad^g  any  special  routines  that  were  built 
externally. 

3.5.8  Evaluation 
Capabilities 

Although  TAE  Plus  does  not  directly  support  map  creation,  it  supports  the  importing  of 
graphics  such  as  geographical  maps  through  the  workspace  object  Once  imported,  these  maps 
can  be  placed  within  a  TAE  Plus  panel  and  easily  zoomed  and  panned.  TAE  Plus  also  supports 
labels,  both  as  pan  of  a  selectable  object  and  as  static  text  The  static  text  labels  can  also 
highlighted  wiA  special  effects  such  as  flashing.  In  addition,  the  text  handling  c^abilities  are 
quite  good.  TAE  Plus  offers  many  high-level  ^splay  objects  that  provide  various  types  of  text, 
such  as  static  text  text  list  text  display,  and  the  page  edit.  Text  input  fields  and  system  output 
fields  can  be  easily  formatted. 

TAE  Plus  provides  many  ready-made,  high-level  display  objects,  referred  to  as 
"presentation  items,"  which  are  very  similar  to  those  of  MOTIF  and  Open  Look.  The  buttons, 
icons,  pull-down  menus,  radio  buttons,  checkboxes,  arxi  text  input  fields  are  quick  and  easy  to 
include  on  any  panel.  The  system  also  supplies  dynamic  objects  such  as  rotators,  stretchers, 
and  stripcharts,  called  "data-^ven"  objects;  many  user  interface  design  tools  do  not  have  such 
a  complete  set  of  interactive  objects.  However,  only  the  ictxis  and  d^-driven  objects  can  be 
defined  and  customized  by  the  developer  in  the  Wo^ench  editors;  the  other  items  carmot  be 
drawn.  The  data-driven  (Arjects  do  not  directly  support  any  type  of  complex  animatimi,  and 
cannot  be  connected  to  any  internally  generate  function.  For  example,  they  would  not  be 
suitable  to  support  a  C31  cfisplay  that  requires  a  map  with  satellites  moving  randomly  across  the 
screen. 


Most  of  the  development  is  done  in  the  WorkBench  via  dialog  boxes.  Idraw  is 
extremely  limited  and  difficult  to  use.  It  is  not  intended  to  be  used  for  extensive  development 
efforts.  TAE  Plus  does  not  allow  much  of  the  "feel"  of  the  interface  to  be  defined  without 
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programming.  The  only  functionality  that  can  be  added  through  the  WoikBench  is  the  panel 
connections.  However,  many  tools  Aat  do  support  definition  of  functionality  independent  of 
coding  cost  significantly  more  than  TAE  Plus. 

To  support  easy  development  of  a  user  interface,  TAE  Plus  provides  a  code  generation 
capability.  The  robust  TAE  Plus  code  generator  produces  programs  that  are  fairly  easy  to 
understand  and  modify.  The  code  is  generated  in  a  modular,  lughly  structured  format  with 
many  embedded  comments.  The  code  has  structures  called  "event  handlers"  within  which  the 
developer  must  insert  code  or  modify  existing  code  extensively  to  define  the  functicxiality  of  the 
prototype.  It  can  produce  a  control  program  in  C  Ada,  FORTRAN,  or  the  TAE  Plus 
Ccnnmand  Language  (TCL). 

Usability 

There  is  no  direct  manipulatitm  of  graphic  icons  and  limited  menuing  in  the 
WorkBench.  Rather,  TAE  Plus  uses  a  set  of  dialog  boxes  that  support  creation  of  panels  and 
presentation  items,  definition  of  their  attributes,  and  sequencing  of  displays.  The  (halog  boxes 
prompt  the  developer  for  each  necessary  piece  of  information.  For  example,  the  first  dialog 
box  prompts  the  developer  to  enter  the  resource  file  name.  The  next  provides  radio  buttons 
that  allow  the  user  to  create  a  new  panel  or  a  presentatirai  item.  Each  of  these  causes  another 
more  detailed  dialog  box  to  appear. 

Dialog  boxes  are  often  considered  to  be  easier  to  use  than  deeply  nested  menuing 
systems.  However,  they  do  not  allow  for  any  direct  manipulation.  Tbere  are  small  puU-down 
menus  attached  to  the  main  develqmient  panel  diat  supply  functions  such  as  rehearse,  generate, 
and  save.  Object  placement  is  handled  by  snapping  presentation  items  to  a  grid.  The  placement 
cannot  be  "tw^w'  in  the  resource  file. 

TAE  Plus  is  limited  in  flexibility.  The  developer  must  be  careful  about  the  order  in 
which  presentation  items  are  created.  For  example,  if  a  static  text  item  is  created  before  a 
button,  die  label  will  be  invisible  when  placed  cxi  tte  button.  The  rendering  of  the  label  can  be 
quickly  accomplished  by  bringing  up  the  label's  dialog  box  and  selecting  the  "OK"  button. 
Similariy,  the  inability  to  mo(^  objects  other  than  the  icons  and  data-driven  objects  is  a 
deficiency.  Many  users  like  to  tailor  the  objects  to  their  application.  For  example,  they  may 
want  the  scroll  bv  on  die  other  side  of  the  window. 

TAE  Plus'  objea  inheritance  rules  can  be  limiting.  The  visibility  of  an  item  cannot  be 
toggled  without  also  toggling  its  parent  panel.  For  example,  if  the  developer  would  like  to 
incli^  a  flashing  "Alert"  button  in  an  interface,  he  must  also  have  the  parent  panel  flash  on  and 
off.  Also,  mice  &  source  code  is  generated,  it  is  difficult  to  modify  the  interface  so  as  to  add 
or  to  remove  items.  This  lack  of  flexibility  is  a  serious  deficiency. 

A  user  interface  prototype  cannot  be  built  with  TAE  Plus  without  programming. 
Although  the  tool  provittes  a  code  generation  functicm,  it  requires  a  great  deal  of  modification. 
Most  of  the  coding  involves  inserting  WPT  calls  in  the  event  handlers."  The  only  functionality 
that  can  be  defined  within  the  WoikBench  is  the  sequencing  from  one  panel  to  the  next 
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TA£  Plus  does  not  support  the  expert  user  as  well  as  it  supports  the  novice  user.  It  can 
take  a  user  about  two  weeks  to  a  month  to  become  proficient  with  the  system.  All  prototypes 
must  be  developed  through  the  WorkBench  dialog  panels.  The  resource  file  are  compiled  into 
binary  at  develt^ment  time.  TCL  files  are  ASCII  ^s,  and  are  interpreted  at  runtime.  Use  of 
the  WorkBench  does  not  require  additional  training.  The  tool  supplies  a  helpful  tutorial  (xi  the 
develq)ment  of  panels  and  ^sentation  items.  The  WPT  library  requires  tie  most  time.  The 
TAB  Plus  documentation  is  useful,  particularly  if  TCL  is  the  develqrment  language.  However, 
TCL  can  have  a  steep  learning  curve  of  its  own. 

TAB  Plus  also  has  a  problem  with  response  time  on  slower  hardware  platforms.  For 
example,  on  a  Sun  3,  TAB  Plus  can  take  sevml  seconds  to  draw  a  panel.  Hnally,  if  the 
resource  file  has  not  been  saved,  TAB  Plus  will  provide  a  confirmation  check  before  the  system 
is  exited. 

Vendor  Support 

The  TAB  Plus  techrucal  support  office  provides  particularly  accessible  and  helpful 
telephone  assistance.  They  also  ofier  half-day  training  courses  at  no  cost. 

Software/Hardware 

TAB  Plus  distinguishes  itself  by  being  based  on  the  X  Window  system.  Much  of  the 
user  interface  rapid  prototyping  literature  states  that  compatibility  with  X  Windows  is  a  goal  for 
tile  future.  It  allows  an  X  Wii^ws-based  interface  to  be  creauxl  without  having  to  include 
calls  to  low-level  XI 1  routines  in  the  application  program.  However,  TAB  Plus  supports 
inclusion  of  independently  drawn  and  maintained  XI 1  Release  3/4  graphics  in  an  application 
created  with  Version  4.1  of  TAB  Plus.  Therefore,  it  can  run  on  any  h^ware  platform  that  can 
run  X  Windows.  This  also  allows  a  prototype  to  be  distributed  across  multiple  hardware 
devices.  T^  Plus  can  also  handle  input  from  both  a  keyboard  and  a  pointing  device. 

3.5.9  Summary 

TAB  Plus  is  a  cost  efiective  user  interface  development  tool.  It  is  particularly  useful  for 
developing  user  interfaces  that  require  a  wide  variety  of  interactive  display  objects  and  have  a 
fairly  well-defined  interface  desi^.  It  does  not  provide  a  flexible  development  environment, 
but  it  does  provide  an  easy  interface  to  the  X  Window  system.  It  also  provides  many 
prefabricate  interactive  objects. 

Perhqts  the  most  important  stren^  of  TAB  Plus  is  its  price.  It  c^ers  a  rather  complete 
set  of  high-level  display  objects  at  a  fraction  of  the  cost  of  the  other  tools  discussed  in  this 
paper.  Other  X-bas^  user  interface  development  tools  include  Builder  Xcessory,  XBUILD 
andUIMX. 


39 


3.6  DATA  VIEWS 


3.6.1  Overview 

DataViews  is  a  product  of  V.I.  Qnporation.  It  is  a  general  purpose  rapid  prototyping 
tool  that  allows  the  develq)er  to  build  a  dyiUmic  graj^c  user  interface.  DataViews  runs  on  a 
wide  range  of  hardware  platforms,  inclutting  Sun,  HP/Apollo,  Sony,  Data  General,  IBM 
R^6000,  VAXstation,  DECstadon,  and  Silicon  C^phics.  Version  9.0  does  not  support  the 
Sony  platform.  It  costs  about  $17,000  per  license.  Although  DataViews  Version  7.0  was 
evaluated  for  this  paper.  Version  8.0  and,  the  latest  version,  9.0  are  also  discussed. 

DataViews  was  originally  developed  to  support  process  ctxitrol  within  a  manufacturing 
envircMiment,  but  it  has  evolved  into  a  general  purpose  rtqrid  prototyping  tool.  It  consists  of 
two  major  components:  the  graphics  editor  DV-Draw,  arid  the  programming  libnuy  DV-Tools. 
DV-Draw  is  a  menu-driven,  dir^  manipulation  graphics  editor  that  allows  displays  to  be 
created,  animated,  and  executed,  independent  of  coding.  DV-Tools  is  an  extensive  library  of 
routines  that  are  callable  from  user-supplied  "C"  code.  These  routines  supptxt  the  dynamics 
and  fiinctiraiality  of  the  interface. 

3.6.2  DV-Draw 

The  DataViews  gr^hics  editor,  DV-Draw,  supplies  both  graphic  primitives,  such  as 
lines,  rectangles,  polygons,  arcs,  circles,  text,  and  vector  text,  and  high-level  display  objects. 
The  display  objects  consist  of  ^phs,  moving  drawings,  and  input  objects.  Version  9.0 
provides  eUipses,  and  supptnts  images  stored  in  the  C^phics  Interchange  Format  (GIF).  In 
DataViews  terminology,  the  graphs  ate  "dynamic  ^ph  ddsplays."  There  are  approximately 
sixty-nine,  in  9.0,  graph  types  within  DataViews,  including  multiple  types  of  bar,  line,  point, 
vector,  and  radial  graphs.  The  graphs  are  complex  drawings  that  can  animated  within  a 
display. 

Through  a  menuing  system,  various  behavioral  characteristics  can  be  assigned  to  the 
gn^hs.  The  behaviors  usually  take  the  form  of  color  or  shape  changes  that  can  \x  based  upon 
an  input  value  from  any  type  of  data  source,  such  as  a  data  file,  an  external  process,  a 
mathematical  function,  a  variable,  or  a  constant.  For  example,  the  bars  witlm  a  bar  graph  can 
be  defined  to  incrementally  elongate  based  upon  a  step  function.  Dynamic  attributes,  such  as 
color,  movement,  scaling,  visibility  and  text  display,  can  be  assign^  to  all  DataViews  objects. 

The  ^ph  object  consists  of  the  graphic  representation,  its  associated  characteristics, 
such  as  axis  tick  marks,  enclo^g  rectangles,  and  the  data  source.  The  moving  drawing  is 
really  a  type  of  dynamic  grt^h  display.  It  can  be  an  object  or  a  group  of  objects  that  move 
across  a  display.  Moving  drawing  allow  an  object  to  move  widi  red-time  positicming.  For 
example,  a  moving  drawing  can  move  as  the  user  inputs  values.  Input  objects  are  objects 
which  allow  the  user  to  interact  with  a  graph,  such  as  a  knob,  dial,  or  pull-down  menu.  New 
objects,  in  9.0,  include  the  menu,  text  entry,  slider,  checklist,  and  radio,  in  both  OpenLook  and 
Motif  styles. 

The  attributes  that  can  be  applied  to  DV-Draw  objects  include  position,  size,  style,  and 
dynamics.  The  operations  which  can  be  performed  within  DV-Draw  include  duplicate,  resize. 
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move,  fill,  lefiesh,  group,  and  zoom.  Scale,  mirror,  rotate  and  reorder  are  the  new  9.0 
operations.  DataViews  ^so  provides  a  "preview"  capability,  so  that  the  developer  can  rehearse 
the  display  dynamics  without  exiting  DV-Draw.  The  preview  capability  can  be  used  to  verify 
that  external  data  being  used  to  drive  the  objects  is  being  transferred  cmiectly.  Version  9.0  also 
provides  a  "prototype"  c^ability"  that  allows  a  prototype  to  be  run  under  DV-Draw  or  under 
UNDC  or  VMS.  I^veloping  a  prototype  with  DataViews  does  not  always  require 
programrtting.  The  develqrer  can  specify  "rules"  within  DV-Draw  to  define  Ae  functionality  of 
display  objects. 

3.6.3  DV-Tools 

DV-Tools  is  an  extensive  library  of  1000  programixting  routines  diat  handle  general 
utili^  functions,  such  as  loading,  displaying,  and  iqrdating  displays.  There  are  routines  to 
marupulate  objects,  to  handle  events,  and  to  provide  a  device-independent  interface  for  display 
devices.  DataViews  also  provides  the  source  code  for  many  sample  "C"  routines  that  handle 
functions  ccMnmon  to  most  prototypes.  For  example,  there  is  a  routine  that  can  be  used  to 
handle  display  sequencing  within  a  prototype.  These  routines  can  serve  as  examples,  or  can  be 
directly  incorporated  into  a  program. 

3.6.4  Prototype  Development  Steps 

To  create  a  prototype  with  DataViews,  the  "look  and  feel"  of  the  display  objects  should 
be  defined  in  DV-E^w.  llie  displays  and  the  objects  can  be  created  via  dir^t  manipulation  of 
the  palette  optimis.  Using  the  menuing  system,  the  develqrer  can  tie  the  objects  to  input  data 
sources.  The  dynarrucs  can  then  be  tested  within  DV-Draw  through  the  preview  function. 
Hnally,  a  "C"  program  with  embedded  calls  to  DV-Tools  can  be  created  to  control  the 
remaining  functimiality  of  the  prototype. 

3.6.5  Evaluation 

Capabilities 

DataViews  7.0  and  8.0  do  not  directly  support  development  of  geographical  maps,  but 
map  can  be  imported  in  a  CAD  format  called  "DXF."  These  objects  can  be  easily  zoomed  or 
parined.  Although  DataViews  does  not  directly  support  toggle  overlays,  it  does  provide  "plane 
masking,"  in  which  bit  planes  can  be  grouped  together  and  defined  as  visible  or  invisible. 
Labels  are  handled  conveniently;  object  labels  can  be  modified  without  having  to  recreate  the 
object  Similarly,  DataViews  provides  text  handling  capabilities,  such  as  text  input  fields. 

DataViews'  high-level  display  objects  consist  of  various  types  of  dynamic  graph 
displays,  which  can  be  animated  bas^  on  user  input  external  dac  files,  or  mathematical 
functions.  It  also  supplies  a  specialized  type  of  graph  called  moving  drawings  that  can  handle 
real-time  positioning,  rather  tl^  following  a  pr^fined  path.  The  animation  of  moving 
(bawing  graphs  can  be  controlled  via  an  input  data  source;  thus  animation  can  be  created 
indepenttent  of  programming.  However,  if  a  number  of  dynamic  objects  must  be  displayed  at 
one  time,  it  is  b»t  in  terms  of  perfcninance,  ro  develop  a  program  to  control  the  X  and  Y 
positioning  of  the  objects.  DataViews  also  provides  scroll  bars  and  pull-down  menus  as  high- 
level  display  objects. 
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DataViews  versions  6.0  through  9.0  can  run  under  the  X  Window  system.  It  is 
compatible  with  the  following  window  managers;  Modf,  OpenWindows,  SunView  and 
DECwindows.  A  protot^  built  widi  DataViews  can  be  distributed  over  a  netwoik. 
DataViews  does  not  prov^  a  code  generaticMi  facility.  It  does  provide  many  sample  programs 
that  handle  common  functions. 

Usability 

DataViews  provides  both  direct  manipulation  of  a  palette  of  objects  and  (q)erations  and  a 
menuing  system.  It  also  offers  an  excellent  color  palette.  The  menus  are  not  shallow;  they 
(rften  consist  of  four  levek,  with  many  options  at  each  level.  The  menus  have  become  more 
complex  as  the  capabilities  provided  by  DataViews  have  increased  with  each  new  version. 
However,  through  a  combination  of  di^t  manipulation  and  menuing  systems,  the  developer 
can  design  an  interface  and  define  some  of  its  functionality. 

The  DataViews  develq)ment  environment  is  flexible.  Objects,  attributes,  behavicnal 
characteristics,  and  programming  can  be  done  in  any  order.  Object  pl^ement  is  handled  using 
a  grid  whose  size  can  be  set  to  dh^eient  widths.  Development  without  coding  is  possible  with 
DataViews  as  long  as  the  "look  and  feel"  of  the  prototype  is  kept  simple.  The  preview 
capability  is  ctmvenient  to  test  the  prototype. 

The  learning  curve  associated  with  DV-Draw  can  be  substantial  due  to  the  nested 
menuing  and  the  wide  range  of  capabilities  available.  The  curve  steepens  still  more  if  the 
prototype  requires  programming  with  DV«Tools.  Many  sample  programs  are  supplied  to  ease 
the  bu^n  of  programming.  However,  understanding  and  modifying  these  progiWis  requires 
a  certain  amount  of  expertise.  It  can  take  two  weeks  to  a  mtxith  to  bectxne  familiar  with  DV- 
Draw  and  DV-Tools.  The  documentation  covers  all  the  capabilities  provided  by  DataViews, 
but  many  subjects  are  treated  superficially.  There  are  also  a  computer-aided  tutorial,  DV-Tutor. 
DataViews  provides  confirmation  checks  whenever  there  is  a  possibility  of  losing  work. 

Vendor  Support 

Installing  DataViews  did  not  present  any  problems.  It  can  be  obtained  for  a  trial 
evaluation  period  V.  I.  Corporation  offers  3  day  training  courses  at  $1000  per  person. 
Telephone  support  was  found  to  be  helpful,  and  somewhat  compensated  for  the  poor  DV-Tools 
documentatiotL 

Software/Hardware 

DataViews  is  compatible  with  X  Windows.  It  is  portable  to  any  machine  that  is  running 
X  and  can  be  distributed  across  a  network.  It  can  accept  input  firom  the  keyboard,  mouse  and 
touchscreen  It  can  accept  data  in  any  format  to  drive  the  d^mamic  graph  displays .  In  fact,  the 
format  can  be  specified  by  the  developer.  The  data  format  is  limit^,  however,  geogr^hical 
mty)  data  must  be  in  a  particular  CAD  format 
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3.6.((  Summary 


DataViews  is  a  general  purpose  n^id  prototyping  tool  that  is  relatively  affordable.  It  is 
particularly  useful  for  prototypes  that  require  a  great  deal  of  dynamic  graphics.  DataViews 
inovides  a  usable  grtyihics  editor  that  allows  bc^  the  "look  and  feel"  of  the  prototype  to  be 
defined  without  programming.  It  also  provides  a  preview  functitm  that  allows  the  developer  k> 
test  the  functitmality  of  the  prototype  within  the  g^hics  editor.  Its  dynamic  objects  can  be 
(hiven  by  any  type  of  data  source,  and  they  can  be  defined  to  move  across  the  screen  with  real¬ 
time  positioning. 

3.7  SET 

3.7.1  Overview 

The  Software  Engineering  Toolkit  (SET)  is  a  software  tool  designed  to  prototype, 
develop,  and  maintain  portable  user  interfaces.  Version  3.4  of  SET  was  evaluated,  lliere  have 
been  significant  improvements  incorporated  into  the  most  recent  version,  3.8.  It  is  a  product  of 
CASCT/PA  Cmporation  of  San  Juan  Capistrano,  CA.  SET  is  available  on  various  platforms 
including  Sun,  IfiVApollo,  DEC  VAX,  DECstadon  and  VAXstation,  Silicon  Graptucs  and  the 
PRIME  SO  Series. 

SET  consists  of  a  suite  of  programming  libraries:  windowSET,  graphicSET,  inSET, 
dataSET,  and  onSET.  The  cost  of  all  five  modules,  including  five  days  of  on-site  training  and 
installadon,  is  $7,500.  The  continents  can  be  purchased  separately,  or  in  various 
combinadons.  Tte  price  of  the  individual  modules  is  under  $2,000  each. 

3.7.2  Draw  Graphics  Editor 

The  newest  version  of  SET  includes  a  number  of  demo  programs  that  can  be  used  as 
sample  programs.  One  demo  is  called  "draw.demo"  which  can  funcdon  as  a  graphics  editor. 
However,  DRAW  is  an  unsupported  pordon  of  the  SET  product  Having  been  created  with  the 
SET  programming  Ubraries,  it  was  intended  to  be  used  as  a  sample  ^plicadcm  pogii. 
However,  the  SET  technical  support  representadves  suggest  using  it  as  a  graphics  editor.  The 
fact  that  it  is  unsuppcHted  means  that  the  SET  technical  support  team  is  not  responsible  for 
fixing  or  recommending  altemadve  methods  to  work  around  software  bugs.  Graphic  displays 
generated  in  Draw  are  stored  in  files  called  "metafiles."  The  contents  of  each  metafile  is  drawn 
as  a  "graphics  frame"  at  the  appropriate  time  during  execudon  of  the  prototype.  A  "frame"  is 
SETs  term  for  a  display. 

There  are,  however,  several  problems  with  using  Draw  as  a  develt^ment  tool.  First,  it 
contains  quite  a  number  of  software  bugs.  Second,  as  an  unsupported  part  of  the  product,  it  is 
not  covert  by  the  telephone  support  or  maintenance  agreements.  Thi^  its  use  in  building 
graphic  frames  will  considerably  slow  down  the  pt^ormance  of  a  prototype.  Moreover,  it  is 
difficult  to  use.  There  are  two  altemadves  to  building  graphic  frames  with  Draw.  One  is  to  use 
the  facility  "Simview"  which  was  released  with  version  3.6.  Simview  allows  the  developer  to 
interacdvely  design  windows,  menus,  buttons,  and  so  on.  The  other  is  to  use  the  ^phicSET 
programming  library.  Using  graphicSET  will  avoid  all  the  previously  mendoned  limitations. 
C)ur  discussion  of  SCT  will  therefore  concentrate  on  the  programming  libraries. 


43 


It  is  necessary  to  define  SET  terminology  before  discussing  the  library  routines.  SET 
frames,  or  displays,  are  generated  on  what  SET  calls  "drawing  pa^."  A  SET  pad  is  an  infinite 
drawing  space  that  can  contain  both  text  and  git^hics.  Since  a  pad  is  infinite,  it  is  desirable  to 
view  o^y  a  portitm  of  it  at  a  time;  a  SET  "window”  allows  a  section  of  a  pad,  specified  by  the 
developer,  to  be  viewed  on  the  screen.  A  window  is  mapped  onto  a  pad  by  spe^ying  a 
"firame.”  A  SET  fnune  establishes  the  boundaries  of  a  SCT  window. 

3.7.3  Programming  Libraries 

Building  a  prototype  with  SET  version  3.4  requires  a  great  deal  of  programming. 
Version  3.8  allows  an  interface  to  be  designed  without  programming.  The  five  components 
that  comprise  the  SET  tool  are  windowSCT,  graphicSCT,  inSET,  dataSET,  and  onSET.  Each 
module  is  a  library  of  special  purpose  routines.  The  five  modules  support  windowing, 
gnq>hics,  interactivity,  data  structuring,  and  portability,  respectively.  WindowSET  is  a 
pomble  window  manager  that  supports  windowing  capabilities  on  a  wide  range  of  text  and 
graphics  terminals.  Versitxi  3.6  and  version  3.8  are  also  compatible  with  the  X  Window 
System;.3.8  is  compatible  with  Motif.  GraphicSET  is  a  graphics  package  that  provides  both 
2D  and  3D  drawing  capabilities.  InSET  is  the  interaction  tumdler  that  provides  techniques  for 
controlling  the  frin^onality  of  the  user  interface.  DataSET  is  a  data-structuring  tool.  And 
finally,  oi^ET  insulates  the  triplication  program  from  the  cqierating  system  to  maintain  the 
portability  of  the  software.  Together,  these  five  monies  provide  the  functionality  to  handle 
every  aspect  of  prototype  development 

WindowSET 

WindowSET  is  a  screen  management  system.  WindowSET  routines  make  a  prototype 
compatible  with  the  windowing  systems  on  Sun  and  DEC  workstations.  Sun  Views  and 
DECWindows.  Version  3.4  is  not  compatible  with  the  X  Window  System.  Compatibility  with 
X  is  a  goal  for  future  versions. 

WindowSET  functitxis  on  two  separate  levels.  It  has  the  capability  to  provide  both  the 
end  user  and  the  developer  with  control  over  a  prototype.  With  the  windowSET  routine 
library,  the  develqier  can  create  and  control  windows  of  various  pre-defined  t)^s.  With  the 
screen  formatting  facilities,  the  end  user  can  modify  the  screen  presentation  while  an  application 
is  running.  Version  3.8  allows  the  screen  presentation  to  be  modified  interactively. 

With  the  windowSET  library,  the  developer  can  create  several  different  types  of 
windows.  The  various  window  types  include  transcript,  read,  message,  edit,  VDU,  and 
graphics  windows.  Transcript  windows  provide  a  wo^  area  for  the  interaction  between  the 
user  and  tire  application  program.  For  example,  they  can  contain  the  application  output  as  well 
as  an  echo  of  the  user  input  from  the  command  line.  Read  windows  allow  the  user  to  list  and 
peruse  (read-only)  the  contents  of  a  file.  Mess^e  windows  contain  help  messages  and 
additional  information  supplied  by  the  application  program.  Edit  windows  are  similar  to  read 
windows,  but  have  toth  read  and  write  capabilities.  ^Us  (visual  display  units)  are  windows 
specifically  formatted  to  contain  text  input  regions,  with  attributes  such  as  highli^ting  and 
color.  Graphics  windows  are  used  for  the  display  of  graphic  entities. 
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The  windowSET  screen  formatting  facility  supplies  the  end  user  with  such  c^abilities 
as  window  selection,  frame  control,  pad  control,  menu  control,  and  text  editing,  or,  if  it  is 
available,  windowSET  relies  on  the  X  Windowing  System.  As  with  most  windowing 
systems,  a  window  is  selected  simply  by  placing  Ae  cursor  within  the  regitm  of  the  window. 
Fnanc  control  includes  resizing,  moving,  copying,  refreshing,  deleting,  popping,  and  pushing 
the  window  specified  by  die  fir^e  boundaries,  ftoviding  that  a  particul^  window  has  been 
defined  as  optional  by  tte  developer,  the  user  has  die  ability  to  delete  that  window  entirely  from 
the  screen.  The  user  can  scroll  the  pad  in  any  direction  to  bring  a  different  portion  within  the 
window  frame.  The  user  can  also  zoom  in  and  out  on  the  pad. 

GraphicSET 

GraphicSET  is  a  graphics  package  that  supplies  the  prototype  developer  with  a  library 
of  routines  supporting  display  generation.  It  provides  all  the  capat^ties  necessary  to  perform 
lower  level  graphics,  such  as  drawing  lines  and  circles.  GraphicSET  has  not  changed  from 
versions  3.4  to  3.8,  except  that  the  d^umentation  has  been  improved.  Graphics^  supports 
creatitm  of  the  following  primitive  objects;  lii%s,  circles,  circular  arcs,  ellipses,  conic  arcs, 
markns,  and  text  All  the  primitives  can  be  combined  to  compose  high-level  ^phic  objects  or 
pictures.  There  are  actually  two  types  of  text:  graphic  and  annotative.  Gra|duc  text  is 
transformed  with  its  parent  object  as  it  is  rotated,  scaled,  and  translated.  Annotative  text  is 
designed  to  be  used  as  labels  and  titles,  rather  tii^  as  part  of  a  graphic  picture,  so  it  is  not 
transformed  with  a  graphic  object  The  attribures  consist  mainly  of  line  styles,  font  styles,  and 
fill  patterns. 

To  accommodate  some  of  the  more  complicated  grt^hics,  SET  has  a  special  file,  Ae 
hierarchical  display  file  (HDF),  that  stores  primitives  (such  as  lines  and  circles)  before  being 
displayed  on  die  screen.  The  HDF  allows  a  complicated  drawing  to  be  broken  down  into  its 
respective  components  and  manipulated  individually.  It  improves  performance  by  eliminating 
the  need  to  redraw  the  complete  picture  when  tmly  a  portion  of  it  is  modified.  The  HDFs  basic 
builtting  block  is  the  segment,  consisting  of  a  number  of  graphics  primitives  grouped  together. 
The  primitives  can  be  a  complete  drawing  or  parts  of  a  drawing,  ^h  segment  owns  its  own 
primitives.  A  segment  may  also  own  other  segments.  There  are  routines  that  open  and  close 
the  segments.  Once  the  prototype  displays  have  been  developed,  it  is  necessary  to  provide  a 
mechanism  for  user  interaction. 

InSET 

InSET,  the  interaction  manager  of  SET,  is  the  module  that  generates  the  control 
program.  The  generated  control  program  consists  of  skeleton  code  defining  the  events  that  may 
take  place  during  the  rurming  of  ^e  prototype.  It  can  be  generated  in  C  or  FORTRAN. 

The  control  program  requires  extensive  modification  by  the  devel(^)er.  The  logical  flow 
of  these  events  is  defined  in  a  separate  file,  called  a  "network"  file,  which  must  be  created  by 
the  developer.  It  is  structured  as  a  textual  description  of  a  state  machine  diagram.  Therefore,  it 
is  easiest  for  the  developer  to  create  a  state  machine  diagram  defining  the  flow  of  control  of  the 
prototype,  and  then  convert  this  diagram  into  a  network  file.  InSET  compiles  the  netwOTk  file 
into  executable  code. 
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DataSET 


DataSET  is  a  data  structuring  system  that  provides  a  suite  of  routines  to  enable  the 
developer  to  store  and  retrieve  data.  It  allows  the  user  to  construa  and  search  a  data  structure 
without  requiring  any  knowledge  of  how  it  is  stored  internally.  DataSET  provides  data 
handling  capabiUties  such  as  dkect  pouiters,  lists,  and  tree  searching,  and  handles  "schemas," 
which  are  compressed  descriptions  of  the  data  structures. 

In  additi(»  to  the  dataSET  lituaiy,  the  SET  developer  is  provided  with  a  database 
development  tool  called  IdS  (Interactive  dataSET).  IdS  combines  the  capabilities  of  dataSET 
and  inSET  to  create  an  interactive  envirotunent  fOT  both  the  novice  and  the  expert  database 
developer.  IdS  prompts  the  inexperienced  user  at  each  step,  while  an  experienced  user  who 
enters  full  cottunands  is  not  bothered  witii  the  prompts.  IdS  contains  the  syntax  to  define  the 
datidrase  schemas  and  to  create  new  databases  from  those  schemas.  It  also  assists  the 
developer  in  opening  and  manipulating  existing  databases.  The  SET  data  structuring  facilities 
can  be  used  alone,  or  in  conjunctitm  with  a  full  database  management  system. 

OnSET 

The  SET  portability  manager,  onSET,  provides  a  wide  range  of  operating  system 
independent  routines.  Features  such  as  message  handling,  file  handling,  input/ouqrut,  and 
character  marupulation  are  handled  by  (xiSET,  which  organizes  the  strftware  so  that  all  the 
routines  witiiin  a  prototype  that  interact  with  the  operating  system  are  grouped  together  in  a 
library  of  files.  Creation  of  such  a  set  of  system  independent  functions  is  what  ensures  the 
portability  of  a  prototype.  The  onSET  software  library  is  available  on  HP/Apollo,  VAX, 
DECstation,  Silicon  Graphics,  and  the  Sun  3/4  workstation. 

3.7.4  Prototype  Development  Steps 

Creating  a  prototype  with  SET  requires  several  steps.  First,  the  developer  must  design 
the  frames  that  mate  up  Ae  interface.  If  the  frames  will  be  programmed  rather  than  built  in  the 
Draw  demo,  die  developer  should  generate  the  generic  application  program  at  this  time.  The 
code  shwld  then  be  mo^ed  with  calls  to  the  graphicSET  library  to  create  the  interface.  Once 
the  "look"  of  die  interface  has  been  completed,  the  developer  should  begin  to  define  the 
functionality.  The  best  apiroach  is  to  define  the  flow  of  control  of  the  application  within  a  state 
diagram,  which  is  then  easily  convertible  into  the  network  description  file  format.  InSET  can 
integrate  the  network  description  into  die  qiplication  program.  Depending  on  the  needs  of  the 
application,  routines  from  the  other  SET  modules  can  be  incorporated  into  the  control  program. 

3.7.5  Evaluation 

Capabilities 

SET  supports  zooming  and  panning  of  gr^hic  entities,  although  it  does  not  support 
development  of  geographical  maps.  A  new  module,  which  became  available  in  September 
1991,  will  ptovi^  raster  and  vector  ^phics  capab^ties.  CASET  believes  this  w^  mate  the 
tool  more  useful  for  developers  wortog  with  geographical  applications.  Within  windowSET, 
SET  provides  a  specialized  type  of  win^w  called  a  "visual  display  unit"  that  functions  as  a  text 
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input  field  This  window  can  be  highlighted  with  color  and  special  effects  such  as  reverse 
video.  SET  also  supplies  two  distinct  types  of  text  labels:  graphic  and  annotative.  Graphic 
text  can  be  used  as  part  of  a  graphic  picture;  annotative  text  can  be  used  as  labels  and  titles. 

The  main  difference  between  tliem  is  that  grt^hic  text  is  transformed  as  its  parent  object  is 
rotated  scaled  or  translated;  aimotative  text  remains  unaffected. 

Version  3.4  of  SET  did  not  provide  any  high-level  objects.  For  example,  it  did  not 
directly  support  selectable  buttons,  which  had  to  be  created  as  (uie-item  menus;  each  button 
requires  approximately  six  lines  of  code.  Implementing  special  features  for  the  buttons  also 
presented  a  problem.  For  example,  the  buttons  do  reverse  video  as  die  cursor  moves  over 
them,  but  they  repeatedly  blink  while  attempting  to  return  to  their  original  appearance.  Many  of 
these  problems  have  been  eliminated  by  3.8's  compatibility  with  X  and  Motif.  In  addition,  the 
blinking  problem  has  finally  been  fixed 

SET  supports  windowing  systems,  such  as  DEC  Windows,  Sun  Views,  Display 
Manager  X  Window  System,  and  Motif.  It  also  provides  a  code  generation  facility.  The 
generated  code  is  a  skelettm  of  the  control  progr^,  and  requires  a  great  deal  of  modification. 
The  code  can  be  generated  in  C  or  FORTRAN. 

Usability 

Direct  manipulatitm  of  graphic  ictms  is  available  within  the  Draw  demo  or  Simview. 
Simview  allows  the  developer  to  interactively  design  displays.  Simview  is  available  in  the  new 
version,  however,  it  has  not  yet  been  evaluated  However,  use  of  the  Draw  demo  is  not 
recommended  Besides  the  fact  that  it  is  unsupponed  during  evaluation  it  produced  an 
unacceptable  response  time.  Fa-  example,  it  was  found  to  c^e  up  to  twen^  seconds  to 
sequence  from  one  display  to  the  next.  With  the  programming  libraries,  this  delay  can  be 
de(^ased  to  approximately  five  seconds,  but  that  is  still  poor  performance.  However,  CASET 
reports  that  they  have  evaluated  the  performance  of  the  latest  version,  and  it  is  good  even  when 
running  under  X. 

With  the  older  versions,  if  the  Draw  demo  was  not  used  all  development  had  to  be 
accomplished  through  programming.  For  example,  the  display  objects  are  placed  on  a  display 
by  specifying  the  exact  screen  X  and  Y  coordinates  as  parameters  to  a  routine. 

There  is  a  big  learning  curve  for  using  the  SET  programming  libraries.  The  learning 
process  was  also  hindered  by  the  poor  quality  of  the  SCT  t^umentation.  The  documentation 
of  many  of  the  library  routines  was  ambiguous  and  incomplete.  Many  of  the  details  necessary 
to  build  a  prototype  were  not  mentioned  in  the  documentation.  The  graphic  SET 
documentation,  in  particular,  and  much  of  the  other  manuals  were  improved  for  3.8.  They 
were  changed  from  a  reference  format  to  a  user's  guide  format. 

Ids,  the  database  development  tool,  combines  the  capabilities  of  dataSET  and  inSET  to 
create  an  interactive  environment  for  both  the  novice  and  the  expert  database  developer.  IdS 
prompts  the  inexperienced  user  at  each  step,  while  an  experienced  user  who  enters  full 
commands  is  not  bothered  with  the  prompts.  However,  this  is  a  small  p^on  of  the  SET 
product.  The  other  components  of  SET  all  require  a  high  level  of  expertise  for  development 
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Vendor  Support 

SET  can  be  obtained  for  a  trial  evaluation  period.  The  vendor  may  also  agree  to  send  a 
representative  to  assist  in  installation.  Because  of  tte  weak  documentation,  training  is  crucial 
Although  the  documentation  has  been  improved,  training  is  still  recommended  for  the  novice 
SET  user.  Training  courses  ate  offered  for  3  days  at  $1000  per  day  plus  traveling  expenses  for 
a  maximum  df  15  students.  The  CASET  telephtme  assistance  was  exceptionally  helpful 

Software/Hardware 

The  onSET  routines  can  be  used  to  port  an  {q)plication  amtxig  the  following  hardware 
platforms:  HP/ApoUo,  VAX,  DECstation,  HP  QOOQ/ApoUo,  Sun  3/41  Sparc,  and  the  Silicon 
Grt^hics  workstation  series.  DataSET  allows  external  data  to  be  access^  by  a  SET  prototype. 
It  can  (Mve  mote  than  one  display  device  at  a  time,  and  can  accept  input  through  the  keyboard 
and  the  mouse. 

3.7.6  Summary 

SET  is  version  3.4  a  useful  tool  for  e^rt  developers  who  would  rather  develq)  a 
prototype  through  high-level  programing  with  the  routine  libraries  than  through  use  of  a 
menuing  system  or  (titect  mattipulation.  Unlike  many  of  the  other  tools,  SET  has  undergtme  an 
extensive  set  of  modifications  during  the  last  two  releases.  An  interactive  graphics  editor  was 
added;  the  documentation  was  improved,  and  the  tool  was  made  X/Motif  compatible.  Use  of 
the  libraries  can  be  a  significant  improvement  over  coding  from  low-level  graphics  packages, 
such  as  CORE  or  GKS.  However,  the  SET  programming  libraries  can  present  a  significant 
learning  curve  even  for  expen  progranuners,  simply  because  of  the  poor  documentation. 
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SECTION  FOUR 


TOOL  SELECTION 

As  the  evaluations  included  in  this  paper  illustrate,  there  is  no  one  "best"  USI  rapid 
prototyping  tool.  Rather,  selection  of  a  tool  must  be  based  upon  a  system's  particular  needs. 
Each  oi  the  tools  evaluate  has  its  own  strengths  and  weaknesses,  and  diese  should  be  fitted  to 
the  system  requirements. 

Fot  example,  if  a  prototype  requires  high-level  display  objects  such  as  scrolling  text 
windows  and  pull-down  menus  superimposed  on  a  set  of  complex  geogrqrhical  map  ^ta,  then 
LUIS/SMS  would  be  chosen.  If,  on  the  other  hand,  the  prototype  is  to  be  a  simulation  of  an 
Air  Force  display  console,  complete  with  dials  and  buttons,  VAPS  would  be  the  appropriate 
tool.  DataViews  and  SL-GMS  might  be  considered  for  development  of  a  more  general  purpose 
prototype,  such  as  different  applications  of  computer  information  systems.  TAE  Plus,  on  the 
other  hw^  may  be  chosen  for  a  prototype  which  requires  many  hi^-level  display  objects  such 
as  radio  buttons,  check  boxes,  and  scroll  bars,  but  which  has  a  limited  budget  to  spend  on 
tools.  SET  is  particularly  useful  for  developers  who  wish  to  do  low-level  gr^hics 
programnting  and  have  complete  control  of  their  development  details. 

In  addition  to  considering  the  functional  requirements  of  a  prototype,  it  is  important  to 
consider  the  skills  and  training  of  the  developers.  For  example,  develq)^  wIk)  do  not  have  a 
great  deal  of  experience  with  software  development  may  choose  to  use  DataViews  over  SL- 
GMS,  as  DataViews  requires  less  programming. 

To  standardize  the  evaluatioi  procedure  and  to  provide  a  basis  for  comparing  the 
strengths  and  weaknesses  of  the  tools,  we  evaluated  them  against  a  list  of  criteria  that  cover  a 
wide  range  of  capability,  usability,  vendor  support,  software  and  hardware  issues.  This  list 
can  i^ply  to  many  types  of  applications,  but  it  focuses  particularly  (xi  command  and  control 
user  int^ace  requirements. 

The  'Tools-At-A-Glance"  tables  help  the  prospective  user  determine  the  "best"  tool  for  an 
tqrplication.  They  show  how  each  of  the  tools  rat^  against  the  criteria.  The  user  can  simply 
select  a  subset  of  criteria  that  are  critical  to  a  particular  application,  and  pick  the  tool  that  is  rated 
highest  against  them.  However,  it  may  be  beneficial  to  assign  weighted  factors  to  the  criteria 
subset  according  to  importance.  For  example,  if  mapping  c^abilities  are  the  most  important 
factor,  assign  it  a  .20.  Direct  manipulation  is  of  medium  imptntance,  assign  it  a  .15.  Next, 
assign  numerical  values,  such  as  tl^,  two,  and  one,  to  the  three  ratings:  check  plus,  check, 
and  check  minus,  respectively.  Now  simply  multiply  the  numerical  rating  score  by  each  weight 
factor  and  add  up  the  total  for  each  tool.  The  tool  with  the  highest  total  score  can  Aen  be 
considered  best  suited  for  the  application.  A  sample  decision-making  chart  is  shown  in  figure  1. 

The  criteria  list  given  in  this  paper  can  also  be  used  as  a  basis  for  other  evaluations.  If 
the  reader  wishes  to  cot^uct  an  evaluation  on  a  tool  not  included  in  this  paper,  he  or  she  can 
use  the  evaluation  criteria  as  a  starting  point  First  a  list  of  pertinent  criteria  should  be 
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Hgiire  1.  Sample  DeciskMi  Matrix  Chart 


compiled,  either  as  a  subset  or  an  extension  of  the  one  in  section  2.  Next,  a  model  benchmark 
prototyp;,  incraporating  all  the  pertinent  criteria  should  be  designed.  The  tool  should  then  be 
used  to  implement  the  benchmark  application.  The  degree  to  which  the  tool  supports  each  of 
the  criteria  can  be  rated  on  the  basis  of  this  "hands-on"  experience  with  the  tool.  To  assist  in 
this  process,  the  author  will  provide  an  on-line  version  of  the  tools-at-a-glance  tables  will  be 
provided  upon  request 

In  conclusion,  USI  rapid  prototyping  tools  can  offer  a  critical  advantage  to  the 
developer  of  a  high-quality  user  interface.  Prototyping  brings  a  design  to  life,  enabling  the  user 
to  and  feel"  tlw  system  specifications  in  action.  Prototyping  tools  offer  the  power  and 
flexibiliQr  to  experiment  with  design  options  before  the  development  stage.  Because  these  tools 
are  often  expensive,  MlTkE/ESD  projects  may  want  to  delay  purchasing  (me  until  they  are 
(xrnfident  it  suits  their  needs.  This  is  where  the  HFE/USI  Specialty  Group  can  make  a 
difference.  Using  our  in-house  library  of  USI  prototyping  tools,  we  offer  the  prospective  user 
demonstrati(ms  and  assistance  in  t(X)l  use,  as  well  as  new  t(X)l  evaluations  on  request.  And  as 
new  USI  rq)id  prototyping  tools  emerge  on  the  market,  we  will  continue  to  evaluate  them,  and 
will  update  this  paper  with  the  results. 
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APPENDIX 


••TOOLS- AT- A-GLANCE”  TABLES 


The  'Tools- At- A-Glance"  tables  summarize  the  user  interface  rapid  prototyping  tool 
evaluations.  Each  tool  is  rated  against  the  critoion  on  a  three  point  scale:  check  plus,  check, 
and  check  minus.  "Check  plus"  means  that  the  tool  directly  supports  the  critericm.  A  "check" 
tells  the  reader  that  the  tool  does  support  the  particular  feature,  but  it  will  require  extra  effort  to 
implement  And  finally,  "check  minus"  means  that  the  tool  does  not  support  the  criterion.  For 
criteria  such  as  compatibility  with  multiple  input  devices  or  hardware  platforms,  a  "check  plus" 
means  that  die  tool  can  support  more  than  two,  a  "check"  means  that  it  supports  two,  and  a 
"check  minus"  means  that  it  supports  only  one.  These  tables  can  be  used  to  determine  the  tool 
"best"  ad^ted  to  an  application. 
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